Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 095 / rbbs_doc.arc / RBBS-PC.DOC < prev next >

Wrap

Text File | 1987-06-07 | 353KB | 6,742 lines

REMOTE BULLETIN BOARD SYSTEM for the IBM Personal Computer Version CPC15.1 Copyright 1983, 1984, 1985, 1986, 1987 by D. Thomas Mack 10210 Oxfordshire Road Great Falls, Virginia 22066 VOICE -- (703) 759-4357 DATA #1 -- (703) 759-5049 #2 -- (703) 759-9659 Jon Martin 4396 N. Prairie Willow Ct. Concord, California 94521 DATA -- (415) 689-2090 Ken Goosens 5020 Portsmouth Road Fairfax, Virginia 22032 DATA -- (703) 978-6360 June 7, 1987 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 TABLE OF CONTENTS Page ----------------- ---- 1.0 INTRODUCTION 5 1.1 The Capital PC User Group 1.2 The "contributions" requested for RBBS-PC 1.3 The "history" behind RBBS-PC 6 1.4 RBBS-PC Update Conventions 11 1.5 Beta Test Sites, Where and Why 12 1.6 An Example of "Users Helping Users" 14 1.7 What's new with CPC15.1B 15 2.0 RBBS-PC "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS 21 3.0 RBBS-PC's SUPPORT POLICIES 22 3.1 RBBS-PC's Vendor Support Policy 3.2 RBBS-PC's User Support Policy 25 4.0 OPERATING SYSTEM REQUIREMENTS 26 5.0 HOW TO GET A COPY OF RBBS-PC SENT TO YOU 26 6.0 FILES RBBS-PC USES 27 6.1 RBBS-PC System Files 28 6.2 RBBS-PC Text Files 30 7.0 INSTALLING RBBS-PC FOR THE FIRST TIME 31 8.0 THE MOST COMMON PROBLEMS ENCOUNTERED WHEN INSTALLING RBBS-PC 36 9.0 PLANNING YOUR USER INTERFACE 38 9.1 Menus Shown to Callers 9.2 Subsystem Prompts Shown to Callers 9.3 Commands Available to Callers 39 9.4 RBBS-PC's "Wrap-around" Command Search 9.5 How to Have a Single Universal Command Line 40 10.0 PLANNING ON HOW TO UNIQUELY IDENTIFY OF CALLERS 42 10.1 How to Set up Identifying and Individuation of Fields 43 10.2 Preloading Identities for Instant Access 11.0 RBBS-PC'S OPTIONAL AUTOMATIC SUBSCRIPTION MANAGEMENT 44 11.1 Setting it Up 45 11.2 An Example 46 12.0 USING THE "CONFIG" UTILITY TO CUSTOMIZE RBBS-PC 46 12.1 Global RBBS-PC Parameters (Part 1 of 3) 47 12.2 Global RBBS-PC Parameters (Part 2 of 3) 49 12.3 Global RBBS-PC Parameters (Part 3 of 3) 51 12.4 Parameters for RBBS-PC "text" Files 52 12.5 Parameters for RBBS-PC "system" Files 54 12.6 Parameters for RBBS-PC "Doors" 55 12.7 Parameters for RBBS-PC's Security 56 12.8 Parameters for Multiple RBBS-PC's/Conferences 58 12.9 RBBS-PC SYSOP Utilities 59 12.10 Use of DOS Subdirectories 60 12.11 Communications Parameters 63 12.12 Parameters for RBBS-PC NET-MAIL 66 12.13 New Users Parameters 67 Page 2 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 TABLE OF CONTENTS (continued) Page ----------------------------- ---- 13.0 THE HAYES MODEM SWITCH SETTINGS AND CONSIDERATIONS 67 13.1 Hayes Modem Switch Setting Considerations 13.2 Hayes Command's Considerations 68 13.2.1 Command to Initialize the Modem 69 13.2.2 Command to Set Up the Modem 13.2.3 Command to Determine What Ring to Answer On 70 13.2.4 Command to Answer the Phone 13.2.5 Command to Take the Phone Off the Hook 13.2.6 Commands to Initialize the Modem Firmware 71 14.0 RBBS-PC's FILE MANAGEMENT SYSTEM 71 14.1 Using a Single Master Directory 74 14.2 Reasons It May NOT be Possible to Use a Single FMS Directory 75 15.0 SETTING UP ".BAT" FILES FOR RBBS-PC 76 16.0 THE USE OF RBBS-PC "DOORS" 77 17.0 THE SECURITY FEATURES OF RBBS-PC 79 17.1 RBBS-PC's Security Features 80 17.2 Examples of Uses for RBBS-PC's Security System 81 17.3 How to Implement the Password File 82 17.4 How to Implement the Security for Download Files 17.5 How to Implement the Security for RBBS-PC Commands 84 17.6 Beware of the "Trojan Horse" 85 18.0 SYSOP FUNCTIONS 86 18.1 SYSOP Commands Within RBBS-PC 18.2 SYSOP's Use of Function Keys 87 19.0 DOS LIMITATIONS ON RUNNING PROGRAMS REMOTELY 89 19.1 How to Get DOS to Monitor Carrier Detect 19.2 How to Redirect Graphic Displays to Remote Users 90 20.0 CONFERENCING WITH RBBS-PC 90 21.0 RBBS-PC's QUESTIONNAIRE FACILITY 92 22.0 RBBS-PC's Standard Interface for Protocol Drivers 95 22.1 Parameters passed to a protocol driver 22.2 Parameters returned by a protocol driver 96 22.3 The protocol drivers available for RBBS-PC 97 22.3.1 Columbia University's KERMIT Protocol 22.3.2 YMODEM, YMODEMG, and IMODEM 23.3.3 Windowed XMODEM 23.0 UPLOADED FILE TIPS 98 24.0 DUE WARNING AND SYSOP'S LEGAL LIABILITY 98 25.0 COMPILING AND LINKING RBBS-PC 99 25.1 Compiling CONFIG and RBBS-PC 25.2 LINKing CONFIG 25.3 LINKing RBBS-PC 101 26.0 LIMITED LICENSE 101 Page 3 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 TABLE OF CONTENTS (continued) Page ----------------------------- ---- 27.0 LIMITED WARRANTY 101 28.0 UPGRADING FROM CPC14-1D TO CPC15-1B 101 29.0 PROPOSED AGENDA FOR A NATIONAL SYSOP CONFERENCE 102 30.0 RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD 103 APPENDICES: A -- RBBS-PC Record Formats 105 B -- RBBS-PC in a DESQview Environment 109 C -- RBBS-PC in a MultiLink Environment 113 D -- RBBS-PC in a CORVUS Network 115 E -- RBBS-PC in an ORCHID or AST PCnet Network 116 F -- RBBS-PC in an Alloy PC-Slave/16 Environment 119 G -- RBBS-PC and 10-NET Network 125 H -- RBBS-PC and the Hearing-Impaired 126 I -- RBBS-PC and the IBM PCjr 127 J -- RBBS-PC Subscription Service 129 K -- RBBS-PC National Listing Service 130 L -- RBBS-PC and the Ark-Paradyne Modem Switch Settings 131 M -- RBBS-PC and the Anchor Signalman Express (MK12) 133 N -- RBBS-PC and the Everex 2400 Modem Switch Settings 134 O -- RBBS-PC and the Promethus 2400G Modem Switch Settings 135 P -- RBBS-PC and the U.S. Robotics Courier 2400 Switch Settings 136 Q -- RBBS-PC and the FASCTOMM 2496 Turbo Modem 137 R -- RBBS-PC and the AT's RS-232 Cable 139 S -- RBBS-PC and BASIC Compiler Patches for "Doors" 140 T -- Using RBBS-PC to access Data Bases Remotely 145 Page 4 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 1.0 INTRODUCTION ---------------- RBBS-PC is a Remote Bulletin Board System for the IBM personal computer, hence the name RBBS-PC. RBBS-PC has two fundamental purposes -- A. to be a catalyst for the free exchange of information, and B. to serve as an educational example of what can be done with BASIC. I distribute RBBS-PC under the trademark "Userware" because RBBS-PC is the sure and present proof that software which is shared becomes better than it was. RBBS-PC is the result of many thousands of man-hours of effort and is what it is today because of the many software contributions and suggestions by members of the Capital PC Users Group and others. Everyone has something that they believe strongly in. For me it is the "Userware" concept and the free exchange of information. As John Naisbitt states in his book, MEGATRENDS, "...the new source of power is not money in the hands of a few, but information in the hands of the many." For this reason I have devoted the time I have in writing, maintaining, and enhancing RBBS-PC over the years. The reason that I am the registered copyright owner of RBBS-PC and grant the limited license that I do is to primarily insure that these purposes are not abrogated. 1.1 The Capital PC Users Group ------------------------------ Because the fundamental purposes of RBBS-PC and the Capital PC Users Group are similar, I package and forward each new version of RBBS-PC to the CPCUG's Software Exchange for distribution. The Capital PC User Group is a Maryland Corporation whose "legal name" is the Capital PC User Group Inc. The CPCUG is an all-volunteer, non-profit organization of according to Section 501C4, Social Welfare, of federal law. All revenues are re- invested in and applied to the CPCUG's education programs. 1.2 The "contributions" requested for RBBS-PC ---------------------------------------------- The "contributions" requested for RBBS-PC can be one of four types: A. Modifications to RBBS-PC, itself, that are documented and distributed as .MRG files against the "base-line" source code that other SYSOP's might elect to incorporate into their version of RBBS- PC (remember RBBS-PC can not be distributed in modified form with violating both the RBBS-PC copyrights and the limited license granted with it's use). B. Publicly distributable software. It can either be "public domain" (i.e. software which the author has relinquished all rights and which may be appropriated by anyone for use in any way), or publicly distributable software (i.e. software in which the author has retained his rights and which may only be used according to the conditions under which the author has designated). C. Equipment or services. Be inventive in light of the CPCUG's objectives under 1.1. If you or your organization can donate equipment, software, supplies, or services to the CPCUG, feel free to do so. If you are so inclined, but before you do so, contact the Capital PC User Group, 4520 East-West Highway, Suite 450, Bethesda, MD 20854. For general information about the appropriateness of the bequest, contact the Capital PC User Group directly. Page 5 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 D. The last level of "contribution" is merely money. This is the one commodity that we are willing to exchange among each other without first having obtained the respect, consideration, etc. of the other party. It is perhaps the easiest to give as it exonerates us from the other levels of "contribution." CPCUG is an all volunteer organization and, of course, money is seldom plentiful. However the essence of CPCUG is the time, ideas, and effort that each of the volunteers contribute to it. For this reason, while money is always appreciated, money is not the best or even the second-best type of "contribution" you could make. Independent of whether you can donate enhancements to RBBS-PC, publicly distributable software, equipment, services, supplies, or money, consider becoming a member of CPCUG. If you wish to become a member of CPCUG, simply send your name, address, home/work phone numbers along with $25 to CPCUG, 4510 East-West Highway, Suite 550, Bethesda, MD 20814. If in the final analysis you feel that you can do none of the above, o remember those who have, o enjoy what they have nurtured, and o keep the faith with those who have gone before you. 1.3 The "history" behind RBBS-PC -------------------------------- Electronic bulletin board systems have been around ever since personal computers existed. The first ones were very primitive and usually consisted of some posted notices and maybe allowed for on-line messages. It must be remembered that the IBM PC was only announced in August of 1981 and first became available in October of 1981. Therefore it is not surprising that the early history of BBS' is associated with non-IBM personal computers. The "early history" of bulletin board systems began around 1978 in Chicago with the CBBS/Chicago (Computerized Bulletin Board System/Chicago). It was created by Ward Christensen and Randy Suess -- members of the Chicago Area Computer Hobbyist Exchange (CACHE). CBBS for the CP/M is written in 8080 Assembler language (11,000 lines of it) and, like the early versions of RBBS-PC (i.e. prior to CPC12-5A), detects the baud rate and the parity of the user when he first signs on from the three carriage returns that the user must enter. About the same time, Bill Abney wrote a BBS for the Radio Shack TRS-80 Models I and II called Forum-80. The earliest BBS that I know of was written for the Apple (who else had personal computers in those days?) called the "Apple Bulletin Board System" (ABBS). It was written by Craig Vaughn and Bill Blue. They later created another bulletin board system for the Apple II called the People's Message System (PMS). Another Apple bulletin board system that came into being was for the Apple II, II+, and IIE as well as the Franklin Ace and it was called the CommuniTree. It was written in the FORTH language by Dean Gengle and several others. When IBM announced its first personal computer, the IBM PC, in August of 1981, there was no BBS for it. In the summer of 1982, Brad Hanson found a prototype version written by Russ Lane in IBM's BASIC on David Crane's Dallas R/CPM\CBBS system. Brad added many fixes and modifications. In the first half of 1983, many members of the Capital PC Users Group's Page 6 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Communication Special Interest Group (SIG) such as Larry Jordan, Rich Schinnell, Gary Horwith, Jim Fry, Scot Loftesness, and Dorn Stickle further enhanced it and added XMODEM file transfer capability until it became known as RBBS-PC CPC 09 in May of 1983. At that time each feature or modification was identified by a new version number; it still ran only under the BASIC interpreter; and was both relatively slow (because of the interpreter) and somewhat unstable (it would normally "crash" at least once each day). Late in May of 1983, I asked Rich Schinnell if there was any "bulletin board" software available for the IBM PC written in BASIC. Rich told me to give Larry Jordan a call. Larry said that he was just getting CPC09 ready to send to Rich Schinnell who at that time was Director of the Capital PC User Group's Public Domain Software Library and that I could get it from Rich. I did, and still have the diskette just as Rich sent it to me -- dated June 22, 1983. Bulletin board systems, historically were the result of a single person or small group of persons' efforts and tended to serve a very narrow interest group -- typically those interested in the medium itself (i.e. PCs, programming, communications, etc.). This was true up to and including RBBS-PC CPC09. In fact, most of the incentive to get the public domain versions of RBBS (CPC09 and earlier) functioning was to introduce the XMODEM protocol to the IBM PC-based community. In this CPC09 was successful and may have been the primary incentive for XMODEM to be included in PC-TALK at all. Since June of 1983 I have authored and released TWENTY-EIGHT versions of RBBS-PC and distributed them exclusively through the Capital PC User Group under the limited license described in chapter 26 of this documentation. At this time RBBS-PC appears to have become the "industry standard" for IBM-type personal computer bulletin board systems. However, even from the very beginning BBSs have excelled whenever: a.) there was a geographically dispersed audience, b.) with a need to exchange highly complex/technical information, c.) in a timely and accurate manner. RBBS-PC's impact has been to open an entirely new medium of communications between people. Rather than as an end in and of itself, RBBS-PC has come to serve as a means to an end -- the free exchange of ideas. On a technical level it is certainly an example that shows "real programmers can/do program in BASIC." I would like to think that RBBS-PC had something to do with IBM and Microsoft coming out with new versions of the BASIC compiler that support communications, sub-routines, local and global variables, file-locking in a networking environment, etc. RBBS-PC represents a fundamental cornerstone, not just a phase, in what can be viewed as a "social renaissance." The three areas that I mentioned earlier in which bulletin boards excel seem to ebb and flow within communities and organizations. RBBS-PC provides an almost instantaneous mechanism by which these needs can be met. Many of the Big 8 accounting firms bring up RBBS-PC's just to fulfill one contract so that the various geographically disbursed members on the contract can communicate across time zones and continents. Unlike radio, newspapers, and television -- RBBS-PC provides a vehicle within which information can be EXCHANGED! That is what makes RBBS-PC so unique. Because the exchange is written, it is structured. Because it is structured, it can be thoughtful. Page 7 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 The "social renaissance" that RBBS-PC represents is the electronic elimination of those barriers that had previously inhibited the "exchange" of information within our society. RBBS-PC provides every personal computer owner with his own "soap-box" in a national Hyde Park. Previously the channels of communication had built-in barriers to "exchange"; with RBBS-PC those barriers begin to cease to exist. While only the most fanatical RBBS-PC trivia experts may be interested, I've gone back and checked all the documentation and releases of RBBS-PC that I've authored and here is the tedious chronology: RBBS-PC Version Release Date of Major Enhancements Number First Version CPC10.0 07/04/83 RBBS-PC first written to be compilable by IBM's BASIC compiler, version 1.0 CPC11.0 08/10/83 RBBS-PC restructured so that all parameters were external (i.e. in the RBBS-PC.DEF) allowing SYSOPs who didn't want to spend the $300 for the BASIC compiler to tailor RBBS-PC to their taste. CONFIG.BAS was first written to generate RBBS-PC.DEF. CPC11.1 09/15/83 Jon Martin contributed UTSPACE.OBJ, a sub- routine that allowed the compiled version of RBBS-PC to determine the amount of free space available for uploading. CPC11.2 10/01/83 The error trapping within RBBS-PC was completely re-written to be more comprehensive. CPC12.0 10/28/83 Tree-structured file directories and the ability to detect that RBBS-PC was in a "MultiLink" environment were incorporated. "MultiLink" is a product of the Software Link, Inc. which allows DOS 1.1, 2.0, 2.1, 3.0 and 3.1 to be "multi-tasking." CPC12.1 12/18/83 The ability for a SYSOP who signed on (Versions A-F) remotely to drop into DOS was added. Also the "New" command was added that allowed users to determine what new files had been made available since the last time they were on. CPC12.2 04/08/84 The security system designed by Ken Goosens (Versions A-D) was incorporated. RBBS-PC's security system has an elegance unmatched even by the largest mainframe. Essentially the security system designed by Ken is "self-locking lock" and, even though RBBS-PC's source code is distributed, it's security system has remained unbroken. Of course, SYSOPs who didn't adhere to RBBS-PC's security structure have had their system "crashed" and every SYSOP should operate as if the very next caller could crash his system. Page 8 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 RBBS-PC Version Release Date of Major Enhancements Number First Version CPC12.3 11/11/84 This was almost as complete and as major a (Versions A-B) re-write of RBBS-PC as CPC10.0 had been. Beginning with CPC12.3 up to nine RBBS-PCs can share the same files in either a multi- tasking DOS environment (i.e. MultiLink from the Software Link, Inc.) or in a local area network environment (i.e. Corvus or Orchid). CPC12.4 03/10/85 RBBS-PC's stature in the industry became (Versions A, recognized when, as author of RBBS-PC, I A1, and B) was granted a license by Microcom to incorporate their proprietary MNP protocol into RBBS-PC. Almost at the same time many manufactures recognized the institution that RBBS-PC had become in our industry and elected to include "RBBS-PC compatibility" in their minimum criteria for the introduction of their new products. RBBS- PC's Vendor Support Program is more fully explained in the RBBS-PC documentation but one direct result of this was the intro- duction of 300/1200/2400 BAUD support in CPC12.4A before most such modems were generally available. CPC12-5 07/14/85 RBBS-PC was enhanced to allow 36 copies of (Versions A RBBS-PC to share the same files in a network and B) environment. RBBS-PC automatically answers the phone and no longer requires each caller to enter up to 3 carriage returns in order for RBBS-PC to detect the users baud rate and parity. Logon to RBBS-PC has been made much more efficient with the USERS file no longer being searched sequentially and the MESSAGES file no longer being read three times. Version CPC12-5B, released August 25, 1985, WAS THE LAST VERSION COMPILABLE BY VERSION 1.0 OF THE IBM BASIC COMPILER! CPC13-1 12/01/85 RBBS-PC was completely rewritten to be (Version A) compilable by both the Version 2.0 of the IBM BASIC compiler ($495 list price) and Microsoft's QuickBASIC Version 1.0 ($99 list price). XMODEM with CRC was added as a file- transfer protocol as well as the ability to display on the color monitor of the PC running RBBS-PC the color/graphics that the remote user sees exactly as he sees them. CPC14-1 03/16/86 RBBS-PC's internal structure was split into (Versions A, two parts -- a RBBS-PC.BAS for the main- B, C, and D) line source code and logic and a RBBS- SUB.BAS for commonly called subroutines. This allows unlimited growth for RBBS-PC by providing multiple "code segments" within RBBS-PC. Support for on-line questionnaires, auto-downloading, and the Columbia University-sponsored KERMIT Page 9 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 RBBS-PC Version Release Date of Major Enhancements Number First Version protocol were also included as well as the option to utilize assembly language subroutines to increase for better performance over their BASIC counterparts. CPC15-1A 03/15/87 RBBS-PC's internal structure continued to (Versions A become significantly more modularized and and B) structured. Major enhancements included a File Management System for directories, additional file exchange protocols, support for managing subscriptions, the ability to run as a local application on a network, configurable command letters, the ability to use any field or to define a new field to identify callers, the ability to individuate callers having the same ID, multiple uploads on a single command line, new A)nswer and V)erbose ARC list commands, and context sensitive help. During the evolution of RBBS-PC I have had the distinct privilege of working with many contributors. Contributions have ranged from suggestions, to software fixes, to significant enhancements, to improved documentation. While I have met very few of these people personally, those whose names I remember are: Doug Azzarito Jim Fox Ronald Koridon James Reinder Jeff Batdorf Warren Fox Steve Lieber Jacques Rodrigue Rod Bowman John Friel Steven Linhart Dick Rohrdanz Randy Brodersen Mitch Geier Joseph Lionelle Rich Schinnell Mike Brown Asa Fulton Scott Loftesness Mark Seiden Sam Brown Jim Fry Harry Logan Andrew Silber Mike Button Kent Galbraith James Ludwick Carl Spencer Vince Castelli John German Matt Malden David Staehlin Rob Cecchino Read Gilgen Carl Margolis Stan Staten Tom Collins Ken Goosens Jon Martin Dorn Stickle Drew Commins Dave Hacquebord Robert Mahoney Terry Steichen Ezra Conger Steve Harrison Sidney Markowitz Randy Sun Ed Copley Gary Hoff Louie McCaw Yew Seng Tan Richard Couture Gary Howrith Wes Meier Terry Taylor Dave Crane Charlie Innusa John Morris Jan Terpstra Everett Delano Loren Jones Bill Newkirk David Terry Don Dewall Larry Jordan Jeregen Nordhausen Arnold Thomsen Charles Doughty Robert Jueneman Harvey Pierce Clark Walker Jack Fond Vern Kallegin Danny Plunkette Kim Wells Randy Fuchs Dave Kleinschmidt Jeff Porter Bob Westcott Robert White Special thanks goes to Ken Rogers of the United States Department of Commerce without whose perception and requests for enhancements for the Department of Commerce's ECONOMIC BULLETIN BOARD configurable commands and automatic subscription support would not have been incorporated into version 15-1A of RBBS-PC. To those whose names have not been mentioned -- apologies are extended. Take comfort in knowing that you live on in the work that you have wrought. Jon Martin is primarily responsible for whatever technical excellence that exists in RBBS-PC -- including the ability to have multiple RBBS-PC's share Page 10 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 the same files. I am not a programmer and didn't even know BASIC until I started writing RBBS-PC and released RBBS-PC CPC10.0 in July of 1983. Jon's commitment to RBBS-PC has at least matched my own. Despite my own ineptness, Jon's patience, understanding, and technical insights have been unfailing over these several years and, I would like to both publicly acknowledge his contributions to RBBS-PC and express my appreciation for his efforts on behalf of RBBS-PC. I'd also like to mention Ken Goosens' efforts on behalf of RBBS-PC. Ken took the time and trouble to wade through the BASIC source code and incorporated the "security" system that exists within RBBS-PC today. Anyone who looked at the source code prior to release CPC12-2A can appreciate the magnitude of Ken's efforts. I wish space allowed me to chronicle the contributions of each of the contributors to RBBS-PC. In an age of cynicism, RBBS-PC and the Userware concept represents an opportunity for each of us to give back to the world something a little better than when we found it. As I said in chapter 1, this is something that I believe in strongly. To each of the contributors to RBBS-PC I would like to say personally "I am very proud of the company that RBBS-PC keeps." All changes to RBBS-PC since CPC10.0 have been "ADDITIVE." By that I mean CPC12.5B will run the same way as CPC10.0. I felt that users should not be forced to choose between features (i.e. I can run either the features on CPC11.2 or the features on CPC12.1). 1.4 RBBS-PC Update Conventions ------------------------------- RBBS-PC continues to evolve and be "debugged." The following coding conventions have been helpful in the past and you are requested to observe them in the future: Updates consist of two types of ASCII files. One called xxxxxx.MRG which are the BASIC source statements for the particular base-line source code component of RBBS-PC to be updated. The lines that have been modified are indicated as being so modified with a comment beginning in column 70 in the format as follows: 4330 QUICK.SCAN.MESSAGES = FALSE ' CPC14-1D These .MRG files can be applied to the base-line source code via Ken Goosens Batch Line EDitor utility program (BLED). The BLED utility can easily create .MRG files as it has both a file compare and file merge function that is specifically geared to the new BASIC compiler's capabilities that allow lines of source to be unnumbered. The second file type is called xxxxxx.DOC. It describes on a line-by-line basis the specific functions added or bug that was fixed. Obviously xxxxxx can be anything you wish to name it. The second type of file is what allows me to integrate several .MRG files and resolve whatever conflicts that may exist. The RBBS-PC naming conventions of CPCxx.x are roughly as follows: 1. If a "bug" is being fixed CPCxx.x will be given a .MRG file name such as CPC14-1D.MRG with a corresponding CPC14-1D.DOC file describing the changes. The first version of CPCxx.x is always "A". When you logon to RBBS-PC the version will be displayed. Page 11 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 2. If, after a release is released, bugs are reported and fixes are found for them, they are distributed via an FIXmmdd.ARC file which contains the necessary files to apply the "temporary fixes" against the released version of the source code and re-compile the source code. 3. If a new feature or enhancement is added the last digit in the CPCxx.x will be incremented by one (i.e. CPC12.2D was followed by CPC12.3A). 4. If a significant change to source code or logic occurs, the first two digits of the release level will change (i.e. CPC14.1 was followed by CPC15.1) The purpose of these conventions is to allow everyone to know what RBBS-PC level they are running under (users as well as SYSOPs) and understand the logic behind the changes/fixes as they occur so each SYSOP can evaluate them for his own needs. If you have comments or fixes please let me know so that they can be reflected in the RBBS-PC program and shared with all other users. You can do that by sending your changes by mail to: D. Thomas Mack 10210 Oxfordshire Road Great Falls, Virginia 22066 or uploading the changes to either of my RBBS-PC lines -- (703) 759-5049 or (703) 759-9659. While comments and suggestions are always welcome, those that are accompanied by the RBBS-PC source code changes that implement them carry a lot more weight than those that don't. 1.5 Beta test sites, Where and Why ----------------------------------- A lot of people volunteer to be "beta test" sites. For those that do it is fitting that you know why each release of RBBS-PC is "beta tested" and what it takes to be "beta test" site. Why "beta test" RBBS-PC? Well, the answer should be self-evident. RBBS- PC has two primary goals -- one of which is "to serve as an educational example of what can be done with BASIC" (see chapter 1). The "beta test" process seeks to put each new release in as varied as an environment as possible in order to resolve bugs in the new features as well as assure that old bugs are not re-introduced by the addition of new features. Why bother? One reason is simple, professional pride in what RBBS-PC is -- the bulletin board standard for the IBM PC industry. Another reason is the recognition of our responsibility to those who have contributed to RBBS-PC and the obligation to not let them down by putting out a shoddy product. What does it take to become a "beta test" site. There are essentially only 12 criteria for becoming a beta test site. First it takes a demonstrated knowledge of the logic (or lack thereof) within RBBS-PC. To demonstrate this users who become "beta test" sites will have either contributed significant enhancements to RBBS-PC or contributed significant fixes to the more esoteric "bugs" that have cropped up in RBBS-PC. The second requirement is a commitment to the "Userware" concept as described in chapter 1 of this documentation. This requires that you insist on accepting neither personal recognition, monetary reward, nor benefit for your contributions to RBBS-PC -- except the self-satisfaction in knowing that whatever you contributed made RBBS-PC (and hopefully) the PC world better than it might otherwise have been. This is often the most difficult requirement for those who would be "beta testers." RBBS-PC does not exist to be a means to some individual's personal gain or ego gratification. Too many people have contributed too selflessly of Page 12 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 themselves to RBBS-PC for this to ever be allowed to happen. For those for whom this is a too difficult requirement, RBBS-PC's totally open architecture provides the .MRG/.DOC mechanism (documented in section 1.4) to allow individual authors of software modifications to RBBS-PC to both achieve individual recognition and monetary reward from those RBBS-PC SYSOP's who want to incorporate such merges and features into their versions of RBBS-PC. Please note that distribution of .MRG and .DOC files is totally consistent with the limited license that is granted with RBBS- PC. Also note that distribution of modified versions of RBBS-PC is in violation of RBBS-PC's limited license agreement. Thirdly, you must be willing to work within the three self-imposed constraints of RBBS-PC (i.e. that it contribute to the free exchange of information, be an educational example of what can be done with BASIC, and that all changes must be "additive."). This requires that you be willing to work within the confines and limitations of the BASIC language, not eliminate earlier functionalities within RBBS-PC (only add new ones), and ALWAYS strive to structure RBBS-PC so as to foster the free exchange of information. The other nine "beta test" requirements in order to become a beta test site require that you must be willing to: 1. Run unmodified versions of the new version of RBBS-PC. 2. Not release any part of what you are beta testing to anyone else. 3. Be willing to have your entire system and hard disk be vulnerable to software flaws in the new version of RBBS-PC. 4. Be willing to FIX the bugs you encounter -- simply reporting them is not enough! 5. Live with the bugs that aren't fixed until they are fixed. 6. Be willing to call and discuss via voice problems (at your expense -- not mine). 7. Be willing to call and download (almost daily during the "beta test" period) 450K files also at your expense. 8. Live with the fact that whatever you are beta testing is not going to be what is actually released and that you will probably have to download what is actually released just like every one else. 9. Be charitable about the author's programming skills. Needless to say, those few who participate in each new release of RBBS-PC typically are not the same people from release to release. This is because of the intensity and time that the relatively short beta test period (typically two weeks or less) makes on the beta testers. Another constraint is my abilities to adequately respond to more than two or three beta testers at most. Finally, like owning a swimming pool or a boat, everyone wants to be a beta tester once! There is little glory and lots of pain. Luckily, Jon and I usually divide up the beta testing based on who lives east and west of the Mississippi river in order to have as many beta test sites as possible. Most of the credit for RBBS-PC CPC15-1B being better than the earlier versions goes to the following beta testers: East Coast West Coast ---------- ---------- Rob Cecchino, Virginia Beach, Va. Rod Bowman, Alta Loma, Ca. Ken Goosens, Washington, D.C. Loren Jones, Fargo, N.D. Dave Hacquebord, Tampa, Florida Gene Lowry, Tuscon, Az. Kim Wells, Largo, Maryland Terry Taylor, San Leandro, Ca. Stan Staten, Gaithersburg, Md. Mike Brown, Madison, WI Page 13 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 1.6 An Example of "Users Helping Users" --------------------------------------- The ability to have multiple RBBS-PC's running concurrently -- either on a single PC in a multitasking DOS environment or in a local area network, is a concrete example of the concept of "users helping users" in action. This ability was developed in support of the efforts of the State of West Virginia Department of Education's "West Virginia Microcomputer Educational Network" project. It is the first statewide microcomputer network and encompasses all of the state's 1,125 schools in 55 different school districts. Each school is intended to have the capability of accommodating up to twenty IBM PC's in a local area network sharing a common 20MB disk drive. As of June of 1984, 83 of the 1,125 schools had such networks. Each PC can communicate with either the LAN, a central library, or with other schools in order to share programs and materials. The key component for this communication is RBBS-PC. In a presentation at the U.S. Department of Education in Washington, D.C. on June 22, 1984, the role RBBS-PC plays was described as follows: "The medium that ties the entire system together -- that allows for communication not only between one school and another but also between schools and the central library -- is an electronic bulletin board (RBBS-PC) This bulletin board will be in operation 24 hours a day at the central site, with a similar bulletin board in operation at every school. The local school bulletin board (RBBS-PC) could be accessed by students who wish to review their lesson or take a test at home provided they had a computer and a modem. Teachers could access their grade book or other reports and lessons at home in preparation for the next school day. Neither bulletin board system (RBBS-PC) requires personnel to answer telephones or transmit files. They are both totally unmanned and operate 24 hours a day. No toll charges, of course, would be assessed for calling the local school bulletin board and toll free 800 numbers are used for accessing the central library." The State of West Virginia arranged to have the vendors involved, IBM and Corvus, make the appropriate equipment available on a "loan" basis so that RBBS-PC could be developed to work in a local area network environment. Since this project conformed so closely to the primary objectives of RBBS- PC, we agreed to volunteer our time and take on the task of enhancing RBBS- PC to allow up to nine (9) copies of RBBS-PC to execute concurrently sharing many of the same files. On a single PC the maximum number of concurrently running RBBS-PC's within the same DOS is limited only by: a. the number of communications ports installed on the PC. IBM's limit is two (COM1 and COM2), but other vendors supply "add-on" cards which provide for up to eight or more communications ports on a single PC. b. the number of communications ports that the IBM BASIC compiler can read and write to. IBM's limit is two (COM1 and COM2). c. the number of concurrently running tasks that can be supported. IBM's DOS is limited to one task. Other vendors provide "add-on" software to IBM's DOS that Page 14 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 provides for up to nine simultaneous tasks. Within a network environment (i.e. multiple PC's linked together sharing the same devices) the maximum number of concurrent RBBS-PC's is set by RBBS-PC's internal design to nine (9). This design was based on the fact that anyone who wanted to run nine RBBS-PC's sharing the same set of files would take the $46,000 needed to buy nine PC's with modems, network interface cards, hard disk (at least 20MB) and purchase a minicomputer for the same amount of money with more ports and storage. CPC13-1A was updated to allow for 36 RBBS-PC'S to share the same files. For those interested in further information on the State of West Virginia's Microcomputer Educational Network, please contact: Mr. John E. Cook State of West Virginia Department of Education 1900 Washington Street East Building 6, Room 221, Capital Complex Charleston, West Virginia 25305 1.7 What's New with CPC15-1B ---------------------------- RBBS-PC CPC15-1B is just a maintenance release containing fixes to CPC15- 1A. RBBS-PC CPC15-1B will be the 29th release of RBBS-PC CPCxx since it was first published in July of 1983. RBBS-PC's policy of freely distributing the source code and continually expanding it's range of capabilities throughout these last four years represents not only the very best that is embodied in the concept of "users helping users" but an expectation of excellence that NO product in the PC industry has ever even approached. Here is a brief summary of the major enhancements in RBBS- PC that began with CPC15-1: o SPEED! RBBS-PC runs significantly faster. o STRUCTURE! Code has been made easier for users to modify. There is more room in the main code segment and RBBS-PC more efficiently uses string space. o MINIMUM SYSOP MAINTENANCE REQUIRED! There is a new, but optional, FILE MANAGEMENT SYSTEM (FMS) that can be set up so that the SYSOP no longer need maintain his file system "directories." Users can be allowed to automatically categorize the files they upload. The new entry will be written to the file management system and, optionally, strewn to a second file that a SYSOP might wish to edit and insert an evaluation or comments about the uploaded files. The speed of file searches has been increased from 10 to 100-fold. A caller can download in the midst of listing files, and the listing will resume where it left off after downloading is completed. o ADDITIONAL FILE TRANSFER PROTOCOLS! More error checking protocols for file exchange. Now support exists for YMODEM, WINDOWED XMODEM, YMODEMG, and IMODEM in addition to KERMIT, XMODEM (checksum) and XMODEM (CRC). o LAN ELECTRONIC MAIL! RBBS-PC can be run as a "workstation" appearing on the local PC's screen exactly as it would to a user who had dialed in as remote user. In "workstation" mode, RBBS-PC can be run on a PC without either a modem or a RS-232 interface. It can serve as an electronic mail system on a local area network in "workstation" mode (up to 36 stations) or as a teaching tool in a classroom environment to demonstrate RBBS-PC's full range of features. Page 15 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 o STORE-AND-FORWARD "NET MAIL" SUPPORTED! RBBS-PC can be called by such "store-and-forward" network mail applications as "SeaDog" from System Enhancement Associates (the same guys who brought the ARC utility to the PC environment). o ALL COMMANDS CONFIGURABLE! The symbols used for the RBBS-PC commands are configurable. Any command can be disabled. Users see only what commands they have sufficient security to execute. A SYSOP can even configure RBBS-PC so that any command can be executed from any sub- section. All of this is, as always, optional. RBBS-PC tries to strive to let each SYSOP have total autonomy (rather attempt to restrict). o MULTIPLE QUESTIONNAIRES! The new command A)nswer command allows multiple optional questionnaires to be set up that users can selectively answer. A SYSOP can put up a questionnaire at anytime that all users (both new and old) must answer. A new command has been added to the questionnaire script language that allows the SYSOP to elect to have nothing written to the script's data file. o USERS CAN VIEW ARC FILES! Users can obtain a verbose listings of the the contents of an ARCed file prior to downloading it. o TOTAL USER CONTROL OF PREFERENCES! A user can now T)oggle on/off any of his preferences. o UNIQUE USER ID'S! With RBBS-PC CPC15-1A, any field (not just the users name) can be used to uniquely identify users. More than one user can have the same ID (everyone in a the same SIG) and still have unique names. A new field for whatever the SYSOP wants to use to identify users now exists within the Users record. Users can be added with no pre-assigned password (i.e. the first caller who uses the name is allowed to set the password). RBBS-PC can be set up so that valid accounts are pre-loaded and users can be given INSTANTANEOUS access at the discretion of the SYSOP, e.g. when the users becomes a member of a user group or SIG. o MULTIPLE UPLOADS! Just as earlier versions of RBBS-PC allowed for multiple downloads, CPC15-1A now allows multiple file names to be specified on a single command line when uploading. o BUILT-IN SUBSCRIPTION SERVICES! RBBS-PC CPC15-1A has built in support for limiting callers based on a subscription date. A subscription period can be specified for every security level, and the security a caller gets when his subscription expires is specifiable. This allows automatic support for SYSOP's who request users to purchase subscription to their boards or for time-limited privileges. Stored in each caller's record is the date the subscription began. o COMMAND-LEVEL HELP! Help files can now be specified not just by section, but by individual command, as well as a menu of SYSOP-specified special topics, such as ARC files. o MUSIC! The SYSOP can elect to have the PC running RBBS-PC to play a musical refrain each time a user selects specific functions (i.e. "Walk right in" when a new user logs on; "Dragnet" when a security violation occurs; "Goodbye Charlie" when a user logs off; "Taps" when a user is denied access; "OOM PAH PAH" when a user downloads; "Thanks for the Memories" when a user uploads). The auditory feedback enables SYSOPS to focus on other activities without having to watch the local screen. More importantly, this type of auditory feed-back is intended Page 16 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 to aid SYSOP's who are visually impaired. o CONSTRAINTS OF EARLIER VERSIONS LIFTED! Many of the constraints that existed in versions of RBBS-PC prior to 15-1A have been lifted. some of them are: The upload directory need not be present on the same drive/subdirectory that uploaded files are written to. When the users file is full, new users need no longer be kicked off the system. Instead, they can be let on but not remembered, i.e. not be written to the users file. On subsequent calls, they will remain new users and must re-register. RBBS-PC can be logged on to from the keyboard of the PC on which it is running (without calling through a modem) and will respond to the PC's screen in the same manner as a remote user would see it. First and last names can have interior blanks. Initial blanks are still not allowed, and trailing blanks are still ignored. SYSOPs can now type while caller is entering a message and their keystrokes will be freely mixed in with those of caller. In earlier versions of RBBS-PC, a SYSOP's local typing was ignored during message entry. The file description for uploads can be up to 46 characters long. The speed with which text files, such as menus, are displayed, can be increased by enlarging the buffer size used within 15-1A for displaying ASCII files via a parameter in CONFIG. Viewing the upload directory (or the uploads with the default category code) is controlled by the users security level. Before, if you made the upload drive not available for downloading, only the SYSOP could view the upload directory. o BETTER ERROR TRAPPING! RBBS-PC CPC15-1 now detects and reports any problem when writing during an upload.; recovers from any problem when trying to kill a file already present before an upload; and traps all bad paths in a file name. o BETTER PROMPTS/MESSAGES! Much effort has been expended to insure that where possible prompts were clarified, messages made more meaningful, and defaults consistently shown. Some examples of this are: The "G>raphics" command was clarified. The prompt makes it clear that ASCII and color options are for IBM computers and the "help" file for the command is automatically displayed when the user is in "novice" mode. "Chat" mode now has a beginning opening and closing message. The prompt for a "P>assword" now clearly states that pressing enter quits. The "N>ulls" command now explains that it is for printing terminals. Page 17 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 "Press [ENTER] to quit" is used more uniformly. Defaults with prompts are more uniformly indicated by putting [] around the default. The List command no longer requires that a directory be specified in advance. The list command used alone will prompt for a directory and default to the directory of directories. The editing command in messages is much easier to use. It no longer requires the user to specify new and old string together but breaks up the edit into a search for what and replace by what. The syntax from earlier versions of RBBS-PC is still supported in keeping with RBBS-PC's long-standing policy of being upward compatible. The prompt when changing page length has been clarified to indicate that the number of lines can have any value between 0 and 255. U>pload and D>ownload commands immediately respond with message "Searching for file...". In some configurations with large (and/or) slow disks a user might see a significant delay with no indication what was going on with this new response. If a 1000 or more files are searched in a directory without filling the screen with "hits", the caller is asked whether he wants to continue the search. Requests for Non-stop in file searches in the L)ist and S)ubstring commands require confirmation if at least a 1000 more files remain to be searched. File searching supports true paging. No longer will the menu or multiple searches scroll away previous results. The pause properly pauses at the bottom. Callers are now informed explicitly whenever an upload or download was successful. Some novices mistakenly thought that errors during transmission mean they had to re-do the transmission. o ENHANCED SECURITY! Paths are now supported in the file security system. Kermit up/down loads no longer list drive/path where then file is located. More secure limitation of DOORS and QUESTIONNAIRES exist since RBBS-PC will no longer accept proper substrings of legitimate items. o NEW DEBUG MODE! Special debug mode has been added to allow all errors, including those that are handled within RBBS-PC, to be seen as they occur. o AUTO-NOTIFICATION! The SYSOP can elect to notify users immediately upon logging on of the number of new bulletins and new files available for downloading since the user last logged on. o TURBO-DOWNLOADING! A SYSOP can allow users to review the files that are new since the user last logged on and download them immediately (without requiring the user to see any messages). Page 18 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 o INVALID DIRECTORIES ELIMINATED! All directories to be searched are put in one specific drive/subdirectory in order to speed up directory searches and simplify maintenance. This eliminates the possibility that data files with the same extension of true directories being considered RBBS-PC directories. o PROMPTS WIPED OFF SCREEN! "MORE" prompts are wiped away after a response, except when files to download are specified. Very useful when more interrupts continuous text, as in menu or message. o RING-NO-ANSWER MINIMIZED! As soon as carrier is lost or the SYSOP takes RBBS-PC off line via function key F1 to use the PC for other things, the phone is taken off the hook so callers will receive a busy single (and not be charged for the call by the phone company). o AUTODOWNLOAD ENHANCED! The SYSOP can select to turn off the automatic test of every user for autodownloading. The escape sequence test for autodownloading caused problems with some communications packages and terminals. Users now can toggle autodownloading on and off during a session and their preference will be permanently remembered. Corrections incorporated in CPC15-1B that fix bugs reported in CPC15-1A are as follows: 1. When creating a new .DEF file or if configuring non-Hayes commands without including the command "S0=" in the modem initialization command no longer results in an ERROR 5 in line 15780. 2. RBBS-PC.EXE, as released, is now compiled against a compiler that has the DTR patch applied. User's should no longer get carrier dropped when they drop to DOS or enter a DOOR. 3. RBBS-PC now correctly handles private messages in conferences. SYSOP's will no longer have USER records randomly "lost." 4. SYSOP's who want their modem's to "auto-answer" and either drop to DOS or run "doors" (despite the vulnerability that they put themselves in) can no do so. 5. The string to initialize the modem when RBBS-PC is configured to answer on zero rings is now correct. 6. RBBS-PC can now select Fox Researches 10-NET as a valid local area network. 7. CONFIG no longer resets the option to invoke the external protocol drivers to "SHELL" rather than to "EXIT" each time CONFIG is invoked. 8. RBBS-PC now more reliably connects with users who are not patient enough to allow auto-baud detect to occur (typically modems with MNP protocol built in have an extra 3-5 second delay for automatically detecting the baud rate of the caller). 9. When a user's subscription expires his USER record is now correctly written. 10. In CONFIG the maximum number of pages displayed is now correct. 11. If a user logs on and selects all upper case output AND color graphics, the color graphics are now correct. Page 19 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 12. RBBS-PC now properly handles the non-FMS ".DIR" files when (1) file searches were not limited to FMS and (2) users could categorize uploads. 13. RBBS-PC no longer always turns on SNOOP. 14. RBBS-PC now dynamically allocates the dummy file "FREESPAC.UPL" that is used to calculate the amount of free space on the upload disk area when assembly language routines are not being used for speed. 15. In a MultiLink environment, RBBS-PC now correctly takes the phone off the hook when either dropping to DOS remotely as the SYSOP (SYSOP function 7) or dropping to DOS locally (Function Key 1). 16. When in local mode, RBBS-PC no longer occasionally issues an "illegal function call" message (i.e. ERROR 5). 17. RBBS-PC now sets the "auto-download" switch correctly. 18. RBBS-PC now recognizes any version EXECPC that responds appropriately as having "auto-download" capability. 19. RBBS-PC no longer can inadvertently generate two USER records for the same user when a caller leaves a protected message to another caller. 20. When answering a questionnaire, the passwords file is re-checked upon completion of the questionnaire. 21. Several locations in the code were corrected to eliminate bad programming techniques (i.e. exiting out of a WHILE/WEND loop) and to make the code more efficient. 22. When RBBS-PC automatically drops to DOS at a specific time each day, the date and time are now recorded correctly in the Node Record. 23. When a user in a "door" drops carrier, the next user who calls in no longer is allocated the time remaining for the previous user. 24. RBBS-PC now gives the 300 BAUD caller a reason that access was denied. 25. Users returning from "doors" or a remote SYSOP from DOS are no longer presented with the "bulletins." 26. When a user says "G>oodbye", the time on the system is now displayed in minutes and seconds instead of minutes and 1/10ths of seconds. 27. Security level for access to "doors" is now checked after the "door" menu is displayed. 28. Read protected messages can now be left when a SYSOP elected to configure RBBS-PC to use individuation. 29. A user's record is no longer lost when switching from a private to a public conference. 30. Locked out users no longer generate a "LOCKED OUT MSG READ" message in the CALLERS file. 31. When running a pre-registered system (a "closed" system) new callers are now shown the file LGx.DEF (where "x" represents the security level for new users). Page 20 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 32. Users that try to join a non-existing conference and find themselves returned to the main message section no longer see prompts that imply that they have successfully joined the non-existing conference. 33. An error can occur in the answering routine which creates a loop when RBBS-PC is counting rings in order to answer the phone. 34. When a 300 Baud caller exits to a MultiLink controlled "door" the system no longer hangs. 35. When a user issues Ctrl/X or Ctrl/K to exit a color menu the colors no longer disappear from the remote user's screen. 36. When using COM0 as a local network user in a multi-tasking environment RBBS-PC no longer hangs when the local user says G>oodbye. 37. ERROR 54 no longer occurs if a user in a private conference changes his password or a SYSOP of the conference uses SYSOP option 5 to do user file maintenance. 38. The W>ho's on command shows only active users on the other nodes and indicates the inactive nodes are "waiting for next caller." Only the SYSOP will see who was last on the inactive nodes. 39. If a user completes an auto-download and then tries an upload, RBBS-PC now handles this correctly. 40. When a SYSOP is doing user file maintenance (SYSOP option 5) and attempts to delete a user, he is prompted more clearly. 41. When a user logs on without supplying his first and last name (separated by a semicolon) followed by a semicolon and his password, RBBS-PC now asks the user to confirm that is the name he wants to log on as. (Only if the SYSOP in using individuation) 42. Error trapping for "disk full" has been enhanced when writing to the CALLERS file. 43. When carrier drops before a user can provide a description for an uploaded file, a more meaningful indicator is now left. 44. Users are required to provide at least 10 characters of description for each file they upload. 2.0 RBBS-PC "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS ---------------------------------------------------------- RBBS-PC CPC15-1B is designed to run on an IBM Personal Computer running IBM's Disk Operating System (DOS), communicating via an IBM Asynchronous Communications Adapter and a Hayes 1200 Smartmodem modem. For RBBS-PC CPC15-1B, the following equipment and software is the MINIMUM recommended: IBM PC with an 80 column monitor, Asynchronous communications adapter (serial port), Hayes 1200 Smartmodem (or 100% Hayes compatible!), Voice grade telephone connection for modem, 25 pin RS-232 modem cable (for stand alone modem), 256K RAM and at least two double-sided drives, PC-DOS 2.0 or higher, and BASIC Compiler (IBM's Version 2.0 or Microsoft's QuickBASIC) Page 21 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 The MINIMUM configuration that RBBS-PC can be run in is on an IBM PC that has 256K of random access memory (RAM), one double-sided disk drive, an RS- 232 communications port with a Hayes 300 baud modem and IBM's PC DOS 2.0 (or higher). However as with ANY bulletin board system, the less disk space available the more file maintenance the SYSOP must do. Also if you choose to allow external file protocol transfers, an additional 136K of memory is required. If you have a second telephone installed specifically for RBBS-PC, ask for a second voice grade telephone line. Data lines are very expensive and are not necessary. The program requires the use of a Hayes Smartmodem (or one that is 100% Hayes compatible) in order to function properly. If your non-Hayes modem doesn't work with RBBS-PC, send RBBS-PC (source code and all) to the vendor and ask him to explain why it doesn't work (i.e. why it is "incompatible" with the Hayes Smartmodem). Callers who come in at even parity and 7 data bits, then try to change to no parity and 8 data bits to use XMODEM, may have a problem if they are using PC-TALK and a Hayes Smartmodem. Switch 1 on the caller's modem has to be down (the factory default position) or the carrier will be dropped when the communication parameters are switched. To avoid this the PC-TALK caller will have to enter the escape code (factory setting "+++"), reset the modem parameters with Alt-P and/or Alt-F, and then return to the "connect" state with the command "ATO." Callers who wish to communicate at 450 baud have to call in at 300 baud then switch to 450 using the N)ew baud selection from the "Utilities" menu. 3.0 RBBS-PC's SUPPORT POLICIES ------------------------------ 3.1 RBBS-PC's Vendor Support Policy ----------------------------------- The only reason RBBS-PC is "hardware-specific" to the IBM PC and the Hayes Smartmodem is that these have pretty much set an industry standard (let's not debate the issue of whether they have also set a "technology" standard). If you follow the code in RBBS-PC closely, you will notice that a great deal of effort was expended in order not to be "hardware-dependent" on either the Hayes or the IBM PC. The purposes of RBBS-PC are outlined in chapter 1 of the RBBS-PC documentation. Those who contribute to RBBS-PC do so without any hope of monetary reward. In fact, great lengths are taken to assure that neither those involved with the development of RBBS-PC nor anyone who distributes RBBS-PC does so for either personal gain or to promote a specific product at the expense of other products. If the hardware you are using is not part of the "base-line" hardware and RBBS-PC doesn't work, your only recourse is to either modify RBBS-PC to meet your particular hardware's needs (that's why the source code is distributed) or contact your vendor and ask him to fix his hardware or modify RBBS-PC (via .MRG/.DOC files) to support his hardware. Since 1984 RBBS-PC became something of an "industry standard." As such several manufacturers have requested that support for their particular hardware and/or software be incorporated into RBBS-PC. These vendors have had three choices: 1. Obtain a copy of the BASIC source code by sending $8 to the Capital PC User Group's Software Exchange. The source code allows the vendor to determine what is required to be "RBBS-PC compatible." Who better knows the quirks of the manufacturer's product than the manufacturer? RBBS-PC's limited Page 22 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 license specifically permits the distribution of ".MRG" files that would allow RBBS-PC to run with whatever idiomatic quirks a specific vendor's product exhibited. The advantage to the manufacturer is that he is in complete control and need not make the .MRG "universal" (i.e. it need only support his product). The disadvantage is that new releases of RBBS-PC come out every six to eight weeks and the vendor would have to review each release to make sure the new releases and his .MRG files were compatible. Of course, as with any other RBBS-PC operator, casual telephone support is available to these vendors. 2. Supply the necessary equipment or software on a loan or gift basis to be used in the testing of future releases of RBBS-PC. This approach has been actively DISCOURAGED for three fundamental reasons. First, the vendor perceives he has "paid" for on-going support by the loan or donation of the product. This is not the case because RBBS-PC's development is an all-volunteer activity. As such, neither I nor any of the others involved with the development of RBBS-PC may have the time nor expertise sufficient to assure compatibility of the specific vendor's product with future releases of RBBS-PC. About all that can be done is to give the vendor our "best effort" to assure compatibility, and advise when it can not be made compatible. Second, the particular product may not have a universal applicability to RBBS-PC users and (or) may not be of interest to those who regularly contribute to the development of RBBS-PC. Both of these conditions must exist before any vendor's product is incorporated into the RBBS-PC development cycle. Third, the price of the loaned or donated products (usually 3 to 5 such products) in no way can even begin to compensate for the hundreds (if not thousands) of development hours required to support other than "base-line" hardware. 3. Establish an on-going institutional commitment to maintain a dialogue between the vendor's engineering group and the RBBS-PC development team along with supplying the necessary equipment or software on a loan or gift basis to be used in the testing of future releases of RBBS-PC. This approach has been actively ENCOURAGED for three different and fundamental reasons. First, the vendor overtly makes an institutional commitment to jointly participate in the development of RBBS-PC. The vendor has the opportunity to supplement the all-volunteer activity that is the basis for RBBS-PC development by choosing to either modify their current or future products to be compatible with RBBS-PC or to supply software that ensures compatibility with RBBS-PC. This benefits all RBBS-PC users. Second, the particular products that fall into this category are required to have a universal applicability to RBBS-PC users (i.e. multi-tasking DOS, networking, 2400 or greater baud capability, error-free protocols, etc.). Also a regular contributor to RBBS- PC's development must be geographically located close to the vendor's development engineers to assure a timely dialogue. Further any regular contributor to RBBS-PC's development who accepts the responsibility for assuring RBBS-PC's compatibility with a particular vendor's product must be willing to do so solely Page 23 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 on a volunteer basis over an extended period of time and in such a way as not to exclude other vendor's products. Only when all these conditions exist is any vendor's product a candidate to be incorporated into the RBBS-PC development cycle. This assures that the RBBS-PC user community has a feed-back mechanism to the vendor's product development and design teams and the vendor is assured of a matching long-term commitment from the RBBS-PC development team. Third, the vendor recognizes that the price of the loaned or donated products (usually 3 to 5 such products) is minuscule compared with the hundreds (if not thousands) of man-hours that may be required from both the RBBS-PC development team as well as the vendor's engineers. This assures that the vendors who choose this third approach are committed to the PC user community. It is precisely this type of commitment that RBBS-PC's USERWARE concept is designed to encourage (from both users and vendors) Vendors who have chosen to make this third type of commitment to RBBS-PC and the PC user community deserve the respect and encouragement of every PC user and are (alphabetically): Ark Electronic Products, Inc. 325 W. Hibiscus Blvd. Melbourne, Florida 32901 (305) 724-5260 Corvus Systems, Inc. 2100 Corvus Drive San Jose, California 95124 (408) 559-7000 The Forbin Project (c/o John Friel III) 4945 Colfax Avenue South Minneapolis, MN 55409 Hayes Microcomputer Products, Inc. 5923 Peachtree Industrial Blvd. Norcross, Georgia 30092 (404) 449-8791 International Business Machines Corporation (Internal Zip Code 2900) P.O. Box 1328 Boca Raton, Florida 33432 (305) 998-2000 Microcom, Inc. 1400A Providence Highway Norwood, MA 02062 (617) 762-9310 Multi-Tech Systems, Inc. 82 Second Avenue, S.E. New Brighton, Minnesota 55112 (612) 631-3550 Orchid Technology 4790 Westinghouse Drive Fremont, CA 94539 (415) 490-8586 Page 24 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Prometheus Products Incorporated 4545 Cushing Parkway Fremont, CA 94538 (415) 490-2370 Quarterdeck Office Systems 150 Pico Blvd. Santa Monica, CA 90405 (213) 392-9701 Racal-Vadic 1525 McCarthy Blvd. Milpitas, California 95035 (408) 774-0810 The Software Link, Inc. 8601 Dunwoody Place Suite 336 Atlanta, GA 30338 (404) 998-0700 The Source 1616 Anderson Road McLean, Virginia 22102 (703) 734-7500 System Enhancement Associates 21 New Street Wayne, NJ 07470 (201) 473-5153 U.S. Robotics, Inc. Skokie, Illinois 60076 (312) 982-5010 Users who feel that they have benefited or who appreciate such commitment to the user community should write or call the above vendors and tell them so, especially if such a commitment influenced the purchase of their products. Similarly, if any user feels that other vendor should make a similar commitment to RBBS-PC and the user community, write to that vendor and send a copy of your letter to the following address: D. Thomas Mack 10210 Oxfordshire Road Great Falls, Virginia 22066 Chapter 22 describes the RBBS-PC standard interface for protocol drivers. All vendors of proprietary protocols who would like to have them added to future releases of RBBS-PC need do is simply conform to this interface. 3.2 RBBS-PC's User Support Policy --------------------------------- RBBS-PC is an all-volunteer effort on my part. Professionally I am not a programmer (as anyone who has looked at the source code can testify) nor an "expert/guru" on personal computers. Since I am not independently wealthy, I have a full time job (unrelated to PC's). As with most other folks, I'm also busy raising a family. What time I can spare from these other activities I am glad to donate to answer questions about RBBS-PC as I believe (somewhat fanatically) in the Userware concept. Page 25 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 However, if you have questions regarding something other than the "base- line" hardware and software requirements outlined in chapter 2.0, DON'T CALL ME. I probably can't help you anyway and even if I do venture some advice it will probably be wrong. One of the axioms of the "Userware" concept is that every user should be able to help themselves -- that's why there are more than 100 pages of documentation and the source code is freely distributed (under a limited license and copyrighted). The only calls that I truly appreciate are those that reveal BOTH a problem and a solution. These I am more than happy to share with anyone and are included in RBBS-PC (either the documentation, the software, or both) as rapidly as possible. Of course, if you encounter a problem and 1. read and re-read the documentation, 2. spend days and days attempting to isolate it, 3. called other SYSOP's and asked their help, 4. looked up any error messages you encountered (they are in the BASIC manual that comes with your IBM PC's DOS), 5. know what version of RBBS-PC that you are running, 6. know what version of CONFIG that you are running, 7. eliminated all other software from your environment, and still can not get RBBS-PC to work, I am most happy to lend whatever telephone advice I can. In this regard, it may help to remember that there are only two types of problems -- MY problems (which are the ones that I can solve) and OTHER PEOPLE's problems (which are the ones that I can't solve). 4.0 OPERATING SYSTEM REQUIREMENTS --------------------------------- Beginning with RBBS-PC version CPC13-1A, RBBS-PC requires version 2.0 or above of IBM's Disk Operating System (DOS). RBBS-PC will not run under the BASIC interpreter. Nor is it reasonable to expect that RBBS-PC would run under ANY other DOS supplied by any other vendor (including Microsoft). 5.0 HOW TO GET A COPY OF RBBS-PC SENT TO YOU -------------------------------------------- RBBS-PC can be obtained by sending a check for $8 to the Capital PC Software Exchange P.O. Box 6128 Silver Spring MD 20906. RBBS-PC is distributed on two double-sided, 9-sector, diskettes. Allow 3 to 4 weeks for delivery -- remember this is an all-volunteer effort. Be sure to specify RBBS-PC CPC15-1B on "diskette # 18". If you want the RBBS-PC source code. CPCUG will ship a third diskette, "diskette # 18S," if you include a second $8 with your order and ask for "diskette #18S." Version CPC15-1B of RBBS-PC's .EXE file is distributed after having been compiled with QuickBASIC Version 2.01 compiler that had the DTR patch described in Appendix O applied to it. This is because Microsoft's QuickBASIC Version 2.0 compiler has a bug in it that causes the local SYSOP's PgUp and PgDn functions to give unusual results. The exigencies of RBBS-PC software releases may mean that diskette 18 contains an earlier version of RBBS-PC than CPC15-1B (either you bought diskette 18 sometime ago or there has been not enough time for diskette 18 to be updated to this most current version). Not to fear! Your $8 has not been wasted. At least two bulletin boards keep the most current Page 26 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 copies of RBBS-PC CPC15-1B for downloading. They are: (703) 759-5049 --+ +---- East Coast (Great Falls, Virginia), (703) 759-9659 --+ (415) 689-2090 ------- West Coast (Concord, California). For those interested, a LaserJet printer ready file of RBBS-PC's documentation is available from the NICBUL RBBS-PC system run by the Nicolet Instrument Corp. by downloading the file named RBSDOCLJ.ARC. The SYSOP is Michael L. Brown and the bulletin board is available Monday through Friday from 6PM to 8AM (Central Standard Time) and all day Saturdays and Sundays. The number is (608) 273-5037. If you want it in "hard copy" form, send a 9.5 x 12.5# envelope with $2.09 in postage to: (one envelope per request) Michael L. Brown Nicolet Instrument Corporation 5225-2 Verona Road P.O. Box 4288 Madison, WI 53711-0288 6.0 FILES RBBS-PC USES ---------------------- There are essentially two types of files that RBBS-PC uses -- "system" and "text" files. "System" files are defined as random files that RBBS-PC reads and writes to. "Text" files are defined as files that RBBS-PC primarily reads from. Text files can be edited externally to RBBS-PC with most text editors that can handle ASCII files. Either type of file can be "static" or "variable" in length. By "static" it is meant that these files have a pre-defined length beyond which RBBS-PC does not extend them. Similarly, "variable" length files are defined as those files whose length is dynamically increased by RBBS-PC. In a multiple RBBS-PC environment only the "static" length files can be shared SAFELY among the various RBBS- PC's. The following table summarizes, using the default file names, which categories the various RBBS-PC files fall into: "Static" Length Files "Variable" Length Files ----- MESSAGES CALLERS /|\ USERS COMMENTS System MESSAGES.BAK 99.DIR (upload directory) Files USERS.BAK upload disk \|/ RBBSxPC.DEF ARCWORKx.DEF ----- QMXFERx.ERR ----- BULLET /|\ LGx.DEF | RBBSxF1.DEF (Created by RBBS-PC) | BULLET1 --> BULLETn | DIR.DIR, aa.DIR --> bb.DIR Text FILESEC and PASSWRDS Files HELPxx | MENU0 --> MENUA | xy.HLP (help for commands) | NEWUSER | PRELOG \|/ TRASHCAN & CONFENCE ----- WELCOME Page 27 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 In a CORVUS network environment any of the "static" length files can be shared on a common volume and ALL of the "variable" length files must be segregated on volumes unique to each copy of RBBS-PC. RBBS-PC issues the NAME function of BASIC in order to determine if a file exists. Because of this, all the volumes accessed by any RBBS-PC in a CORVUS network must be designated "read/write." Therefore, you must be very careful when running CONFIG.BAS. CONFIG creates the definition file (RBBSxPC.DEF) for each copy of RBBS-PC. In a MultiLink (from the Software Link, Inc.) environment and in Orchid's PC-NET environment the vendors claim that not only all the "static" length files can be shared on a common volume but also some of the "variable" length files can be shared. However, if you want to be as conservative as possible, run RBBS-PC in ALL environments as if it where running in a CORVUS network environment. However, if you rely on the vendors claims, in either a MultiLink or PC-NET environment, when running CONFIG.BAS which creates the definition file (RBBSxPC.DEF) for each copy of RBBS-PC, you must be careful to put at least the CALLERS file on an unshared volume. 6.1 RBBS-PC System Files ------------------------- As shown above, "system" files are both static and variable in length. The system files used by RBBS-PC are: MESSAGES - This file is a random file that contains the message text for the RBBS-PC system. The first record in the file contains the RBBS-PC "checkpoint" record. The records immediately following this first record are the RBBS-PC "node" records. The rest of the file consists of message header records which are followed by the message text for that header. Appendix A describes the fields and their uses within the various type of records of the messages file. RBBS-PC expects the MESSAGES file to exist and to have been created by CONFIG.BAS. If CONFIG.BAS does not find the MESSAGES file or it finds one in pre-CPC12-3A format, it will create it and initialize it to the size the SYSOP specifies. Because of the fixed length records in this file, it should not be created or edited outside CONFIG. When the SYSOP "packs" the message file using CONFIG, the file MESSAGES.BAK is created to hold the old messages in case the "pack" is unsuccessful (i.e. not enough space to duplicate the message file). If the disk fills up during the pack function RBBS-PC will recover the message file using MESSAGES.BAK. When the messages file is successfully packed, the pre-packed messages file is renamed MESSAGES.OLD and the temporary file MESSAGES.BAK is renamed MESSAGES. The MESSAGES file should only be "packed" in a multiple RBBS-PC environment when there are no RBBS-PCs active. The MESSAGES file can be shared among multiple RBBS-PCs. USERS - The USERS file is a random access file that has a record for each user who used the system. The record contains a profile for each user who has logged onto RBBS-PC. Appendix A describes the format of the records within the USERS file. The records are 128 bytes in length and are automatically maintained by RBBS-PC. The SYSOP can do some limited editing using SYSOP function 5. To initialize the system simply ERASE this file. RBBS-PC expects the USERS file to exist. If CONFIG.BAS does not find the file on the system it will create it to the size specified by the SYSOP. The USERS file should not be created or edited outside CONFIG.BAS. When the SYSOP "packs" the user file using CONFIG.BAS, the file USERS.BAK is created to hold the old users in case the "pack" is unsuccessful (i.e. not enough space to Page 28 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 duplicate the users file). If the disk fills up during the pack function RBBS-PC will recover the USERS file with USERS.BAK. When the users file is successfully packed, the pre-packed users file is renamed USERS.OLD and the temporary file USERS.BAK is renamed USERS. The USERS file should only be "packed" in a multiple RBBS-PC environment when there are no RBBS-PC's active. The USERS file can be shared among multiple RBBS-PC's. CALLERS - This file is a random file that contains a log of all callers as they log on to the system along with callers city and state, the date and the time. The names are added to the end of the file as well as are the names of the files uploaded/downloaded by the caller. If the file is not found RBBS-PC will create a new one. The file should be ERASED to clear the log. The CALLERS file cannot be shared among multiple RBBS-PC's. COMMENTS - This file is a sequential file that contains any comments that have been left by users for the SYSOP. The file can be scanned by a SYSOP function or it can be TYPEd or edited outside the RBBS system. A SYSOP function is available to delete this file, or it can be emptied outside of DOS. The file will be created by RBBS-PC if it is not found. The COMMENTS file cannot be shared among multiple RBBS-PC's using CORVUS' "OMNINET". This file can be shared using MultiLink or Orchid. 99.DIR - The file on the upload disk that is to have the name, file size, date, and description appended to it of files that have been uploaded. The 99.DIR file cannot be shared among multiple RBBS- PC's using CORVUS's "OMNINET", but can be shared using MultiLink or Orchid. RBBS-PC.DEF - This is an ASCII text file created as output by the CONFIG program. It contains the configuration parameters for the RBBS. It is read by RBBS to determine the configuration settings tailored to your RBBS- PC. In a multiple RBBS-PC environment the definition file for each RBBS-PC is named RBBSxPC.DEF where "x" is a number 1 through 9 , 0 (for the tenth copy), and A through Z (for the eleventh through 36th copy) corresponding to which copy RBBS-PC it describes. In a single RBBS-PC environment the name will be RBBS-PC.DEF. ARCWORKx.DEF - This file is created as output by the ARC view command and contains the contents of the ARC file being inquired against. QMXFERx.ERR - This file is created as output by QMXFER.COM to notify RBBS- PC of the results of an external file protocol transfer. x.BAT - This file is created when external protocol drivers are invoked by SHELLing in order to allow command lines longer than 80 characters. RBBS-PC displays on line 25 the status of those files which must be locked in a network environment. The lock status of the message file is displayed in positions 68 & 69. The lock status of the user file is displayed in positions 71 & 72. The lock block status is displayed in positions 74 & 75 and comments/uploads share positions 77 & 78. The letter "U" in the first position shows that the file is currently "UNLOCKED". The letter "L" in the first position indicates that the file is "LOCKED". Page 29 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 6.2 RBBS-PC Text Files ----------------------- Similarly, the RBBS-PC "text" files are both static and variable in length. The "text" files used by RBBS-PC are: BULLET - This is a text menu file that is printed following the WELCOME file when a user first enters the system. It must be present if "CONFIG Utility parameter # 43" is greater than 1. It can also be called from the main menu with the <B>ulletins command. BULLET1 --> n -- There can be 1 to 99 "bulletins". RBBS-PC will check for the existence of a file whose name consists of the prefix given by parameter 44 of CONFIG.BAS appended with the bulletin number and using parameter 41 of CONFIG.BAS to determine the drive to find the bulletin on. Users can elect to have displayed two different types of "graphics" files for such standard RBBS-PC system files as HELPxx, BULLET, MENU's, etc. In order for a user to see either of these two different types of "graphics" files, the following must have occurred: logged on N/8/1, requested graphics (either full ASCII or "color/music"), and the file must exist and the filename end in either: "G" for files containing the graphic ASCII characters whose values are in the range 129 to 256, or "C" for files containing combinations of the full 256 characters that the caller's communication software can interpret and translate into colors and music (e.g. PCTK666, QMODEM, and EXECPCT). RBBS-PC will check to see if a "graphics" files exists by appending a "G" or "C" to the file name. If such a file can't be found, RBBS-PC will check to see if a non-graphics file exists (i.e. one without the "G"). RBBS-PC will display the first file it finds or a message that the file can not be found. DIR.DIR, aa.DIR --> nn.DIR -- At least one DIR.DIR file has to be present on one of the drives available for downloading. Alternative directories, aa.DIR --> nn.DIR (see chapter 14), should be meaningful and should be reflected in the DIR file. FILESEC - is more fully described in section 17.4 on security. HELP -- There is a help file for each command which has the format xy.HLP, where x is the first letter of the section (M,F,U) and y is the command letter. There are also the following special help files: MAIN.HLP -text file that is printed when <H>elp is requested on the main function prompt. It contains command information. HELP03 -text file that describes the message protection options when <?> is entered after the message <E>nter command is executed at the main message menu. HELP04 -text file that describes the message entry subfunctions when <?> is entered at the subfunction prompt. FILE.HLP -text file that is printed when <H>elp is entered in the files subsystem function prompt. Page 30 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 HELP07 -text file printed when <H>elp is requested at the message read prompt. UTIL.HLP - text file printed when <H>elp is requested in the utility subsystem function prompt. HELP09 -text file printed when <H>elp is requested for type of graphics a user wants (none, ASCII, color/music). MENU0->A -- contain the local SYSOP's menu and menu of various commands for the subsystems. It is recommended that these be placed on an electronic disk drive (i.e. RAM) rather than on a floppy or hard drive. NEWUSER - This is a text file that is displayed for new users just before registration occurs. PASSWRDS - is more fully described in section 17.3 on security. PRELOG - A text file displayed to users prior to logging on. TRASHCAN - is a text file that contains names that the SYSOP finds objectionable and does not want used as either a users first or last name. RBBS-PC uses this file, if it exists, to deny access to anyone using one of these names for either their first or last name. WELCOME - is a text file that a user first sees upon logging onto the system. It must be present, and it should be modified to identify your system. Similarly each "conference" can have a "welcome" file by having a file whose last character ended in a "w" (i.e. conference "RBBS" would have a message file named RBBSM.DEF and a user file named RBBSU.DEF if it where a "private" conference and a welcome file named RBBSW.DEF). CONFENCE - A text file displayed to users who issue the J)oin function from the main menu. It can be created by any text editor that can create an ASCII file and should contain a list of the available conferences. LGx.DEF - This is the file displayed to a user whose security level is below the minimum to log on. The "x" defines the security level of the users who would see this file. A SYSOP can "lock out" users (i.e. give them a security level below the minimum to logon on) for various reasons. This allows users to know why they are not allowed to log on (i.e. LG4.DEF explains because of security violations, LG-1.DEF because of inappropriate behavior, LG-99.DEF because he has never uploaded anything or answered a messages in the last 22 months, etc.). RBBSxF1.DEF -- This is the file dynamically created when the local SYSOP wants to drop to DOS. 7.0 INSTALLING RBBS-PC FOR THE FIRST TIME ----------------------------------------- RBBS-PC, unlike simpler applications such as games and utilities, is a complex application that requires someone who wishes to set up RBBS-PC to already be familiar with modems and PC communications. This section is intended to provide a step-by-step approach to setting up RBBS-PC for the first time. Follow the steps thoughtfully! Do not proceed to subsequent Page 31 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 steps until you understand all the previous steps. Because RBBS-PC attempts to provide SYSOP's the maximum flexibility, it is perfectly possible for those setting RBBS-PC up for the first time to shoot themselves in the foot. Be patient with yourself. Remember that things worth achieving usually are not obtainable without effort. Because of the prevalence of hard disk usage these days, the following assumptions about the hardware to be used to set up RBBS-PC has been made: 1. IBM PC or XT with a hard disk (previously formatted!) 2. Minimum RAM of 256k 3. Hayes 1200 external modem 4. Dedicated 'voice grade' phone line SOFTWARE REQUIRED 1. IBM PC-DOS 2.0 or higher to adequately support a hard disk 2. RBBS-PC.EXE - the main program 3. CONFIG.EXE - the setup program 4. RBBS-PC.DOC - the documentation file 5. ALL of the RBBS text files: MENU1 - MENU5, HELPxx, *.HLP, WELCOME, DIR.DIR, xxxxxxxx.DIR, PRELOG, BULLET, BULLETxx 6. A text editor (PE2, WS non-doc, EDLIN, etc.) to create other useful/needed text files. Your editor MUST be capable of saving spaces (hex 20's) as characters and not substitute tab characters for strings of spaces. Those mentioned above ARE. 7. WATCHDGx.COM - an external carrier monitor prgm. x=COMx: available from most RBBS-PC systems. 1. [ ] PRINT A COPY OF THE DOCUMENTATION! 2. [ ] Have dinner or take a nap while the previous step executes. 3. [ ] Create a sub-directory in which RBBS-PC is to reside. 4. [ ] Change current directory to the newly created directory CHDIR \RBBS. 5. [ ] Create a sub-directory called NEW for your uploads. 6. [ ] Create any other sub-directories you desire to hold downloads MKDIR TURBO MKDIR PATCHES MKDIR UTILS etc. as sub-directories of C:\RBBS The following is a suggested 'layout' of the sub-directories and files which comprise RBBS. C:\ COMMAND.COM \DOS \RBBS RBBS.BAT RBBS-PC.EXE CONFIG.EXE WATCHDGx.COM MESSAGES USERS MENU1 MENU2 MENU3 MENU4 MENU5 HELPxx Page 32 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 *.HLP WELCOME PRELOG (OPTIONAL) BULLET BULLET1 (HOWEVER MANY) FILESEC PASSWRDS TRASHCAN CALLERS (WRITTEN BY RBBS-PC) COMMENTS (IF NOT USING COMMENTS AS MESSAGES WILL BE CREATED BY RBBS) \RBBS\NEW UPLOADS.DIR (Whatever your users upload will go here) \RBBS\DIR DIR.DIR TURBO.DIR UTILS.DIR \RBBS\DNLOADS (Whatever your users can download you must put here) 7. [ ] Copy RBBS-PC.EXE to the current directory (C:\RBBS should be). 8. [ ] Copy CONFIG.EXE to the current directory. 9. [ ] Copy all MENU and HELP files to the current directory. 10. [ ] Create a text file which will serve as your bulletins menu (default = BULLET) using your text editor. Normally, it is desirable for this to be a single 23-line page or shorter. This is to serve as a 'menu' for the user to select bulletins for reading by choosing a number (1-99). Each bulletin file you create will be named BULLETxx where xx = the number on this menu file. The following illustrates what you might create: +----------------------------------------------------------------+ | Bulletin Menu | |----------------------------------------------------------------| | # | UPDATED | SUBJECT | |----------------------------------------------------------------- | 1 | 01/01/80 | TOPIC OF BULLETIN #1 (BULLET1) | | 2 | 01/01/80 | TOPIC OF BULLETIN #2 (BULLET2) | | 3 | 01/01/80 | TOPIC OF BULLETIN #3 (BULLET3) | +----------------------------------------------------------------+ 11. [ ] Create a text file for each bulletin that are going to be available BULLET1 BULLET2 ... etc. making certain that the contents of each corresponds to the indication in the bulletin menu file. 12. [ ] To support all of the graphics options of RBBS you will need a separate BULLET file (BULLETG for IBM-ASCII and BULLETC for ANSI graphics). This naming convention (suffix of G or C) applies also to the menus and the directory files. If disk space is, or is anticipated to be, a problem use of only one set of menu. Graphics or color menus and bulletins are entirely optional and RBBS-PC will run fine without them. 13. [ ] Create a text file named PRELOG. Although this file is truly an an option, it is a good place for announcements which you want all callers to see. If your system restricts new users to 1200 baud or higher it is also a good place to let 300 baud callers know why they cannot log on. 14. [ ] Create a text file named WELCOME (WELCOMEG, WELCOMEC, if desired) which can contain anything you'd like to express to your callers in the way of a greeting or other info. Many SYSOPS use this file to display their 'logo' and a brief description of the equipment they are using. Page 33 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 15. [ ] Now we come to the text files which are the most hassle, both to create initially and to maintain. The files list(s) which are called directories in the documentation. These text files require a very specific format (illustrated below) because RBBS-PC searches for information based on the fields being pre-determined lengths. The top of each file should be a 'header' which describes the contents of the list (utilities, newfiles, etc.). ************************************************************************ HEADER ILLUSTRATION HEADER ILLUSTRATION HEADER ILLUSTRATION ------------------------------------------------------------------------ NAME.EXT SIZE DATE DESCRIPTION ************************************************************************ RBBSCRIP.ARC 2560 07-20-86 QMODEM SCRIPT to log you onto RBBS's PC-QUIZ.ARC 34048 07-19-86 Used to quiz or as a trivia game DB3AR.ARC 53248 07-17-86 dBASE ]I[ Accounts Receivable Package ^ ^ ^ ^ 1 14 24 34 NOTE THE NUMBERS UNDER THE CARETS! They indicate the starting column for each field. Fortunately, the starting columns are the same for the output of the DOS 'DIR' command which by re-directing the output to a file will take care of the structure of the first four fields. You'll need to delete the time of day which DOS will include in the output. One last comment on the 'directory' files, it will be to your users' advantage if you arrange the listings in descending date order (most recent first) as illustrated above. 16. [ ] You will want a ".DIR" file to correspond to each of the DOS sub- directories available to your users for downloading. 17. [ ] Create a text file named DIR.DIR which contains a list of the available .DIR filenames (minus the extension) and some brief description of how the user may view these lists. i.e. L;XYZ or L;123 Now for some suggestions: 1) Place all your .DIR files in the same subdirectory. 2) If you don't want your upload directory seen, do NOT place it in with the other .DIR files. 18. [ ] Create a text file named FILESEC which is one of the most sig- nificant of the SYSOP generated files since it gives you total control of which files & sub-directories are available to you or your users for downloading. Files may additionally be protected from downloading by password(s) which RBBS will require of the user if the file is requested. The format of this file is VERY specific as are the other security related files you will create. An illustration of what a FILESEC file might look like is as follows: FILESEC - the first three examples are protected internally by RBBS-PC from downloading even by the SYSOP, but make good examples anyway. C:\RBBS\*.DEF,10, Downloadable ONLY by security level 10's C:\RBBS\CALLERS,10,CTSA ONLY by security level 10's who know password CTSA C:\RBBS\COMMENTS,,CTSA Any security level who know password CTSA C:\COMM\*.*,,CTSA ALL files in \COMM protected requiring pswd. CTSA 19. [ ] Create yet another text file named TRASHCAN which is checked by RBBS-PC when a newuser logs on, it will contain a list of the user names which you will not permit on your system. These might Page 34 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 include sexually oriented or derogatory terms, computer jargon, common abbreviations, etc. TRASHCAN - this file contains a list (in UPPER case) of names which you do not wish to have as user names on your system. This could include foul language or anything you consider undesirable names. Each word has to be on a separate line and end with a comma. BITE, BYTE, GLADIATOR, THE, 20. [ ] Create a text file named PASSWRDS from which you may control the the logon duration of various user security levels and/or permit extending the current logon of a user through knowledge of specific passwords. Again, the format of this file is critical to its functionality. PASSWRDS - This file permits control of logon durations by security level and a way of extending the current session by the user changing to a temporary password. ,5,45, all level 5's have 45 mins. LONGER,5,90, by using the TEMPORARY password LONGER 5's get 90 mins. ,6,60, all level 6's have an hour ,10,360, all level 10's have three hours NOTE: Four commas are required on each line, passwords MUST be in uppercase, and each line must end with a carriage return. 21. [ ] There is one more text file which you may wish to utilize. Named NEWUSER it is shown only to those persons signing on to your system for the first time. It can contain anything which you want a newuser to know about the system (ground rules, conferences, etc.). It is displayed immediately prior to the caller being asked to C)hange his logon data, D)isconnect, or R)egister on the system. 22. [ ] Create a batch file (RBBS.BAT is the one suggested in chapter 15 of the documentation) which can be very extensive or minimal depending upon your needs/desires. A minimal one is listed here for your convenience. Page 35 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 C: ;change to your default RBBS drive CD\RBBS ;change to the BBS directory IF EXIST RBBSxF1.DEF DEL RBBSxF1.DEF ;cleanup exit IF EXIST RCTTY.BAT DEL RCTTY.BAT ;cleanup if returning ;from DOS/DOORS WATCHDGx OFF ;turn off external carrier monitor prgm. RBBS-PC ;invoke the BBS prgm. WATCHDGx ON ;turn on external carrier monitor prgm. IF EXIST RBBSxF1.DEF GOTO EXIT IF EXIST RCTTY.BAT RCTTY.BAT ;start remote console ;operation via this ;dynamically built .BAT CD\RBBS ;return to BBS directory if not current dir. RBBS.BAT ;restart the loop :EXIT ;exit RBBS-PC if F1 pressed 23. [ ] Now with documentation in hand type CONFIG and press Enter. After a welcoming screen is displayed you will be asked if you will be running multiple nodes - for this discussion it is assumed that you have only one phone line. So type NO and press the Enter key. In a few seconds you will see the main configuration menu, press the F1 key to access the first 'page' of the setup options. CAREFULLY answer each of the questions regarding SYSOP names, etc. If you are unsure of how to respond - refer to chapter 12 of the documentation. 24. [ ] Check that your modem's configuration switches have been set to the positions indicated in the docs (for Hayes 1200 external UUDDDUUD) or to the corresponding functions as listed in the documentation for your "Hayes-compatible" modem. This step can be tricky if your modem is not among those detailed in the documentation - even with the modem manual in hand. But you knew this when you saved all that money by purchasing a non-Hayes modem. 25. [ ] Press the 'End' key, respond 'YES' at the prompt and press Enter. This creates a file named RBBS-PC.DEF in the current directory. During the execution of CONFIG.EXE it will have also created two additional files (one for the user file and one for the message file) using the names you specified, or USERS and MESSAGES if you accepted the defaults. 26. [ ] Turn on your modem if external. 27. [ ] Look at your CONFIG.SYS and AUTOEXEC.BAT files and eliminate any terminate and stay resident software. 28. [ ] Make sure you are running with IBM's (not Microsoft's) PC DOS. 29. [ ] Type RBBS and press Enter. You're on your way as a SYSOP! 8.0 THE MOST COMMON PROBLEMS ENCOUNTERED WHEN INSTALLING RBBS-PC ----------------------------------------------------------------- IT CONTINUALLY RECYCLES! This is caused by one of several things. The most likely cause is that you have not set your modem correctly and the carrier detect (DTR) signal is always "true." Most modems allow this to be set either as always true (that is what is causing the recycling) or only true if there is a modem on the other end that is generating a carrier signal. If you have an external modem, bring up RBBS-PC with the modem cable removed from the PC. If you have an internal modem, bring up RBBS-PC on a PC that has a RS-232 interface. In either case if the problem ceases, then set your modem's switches so that DTR is not always true. If your modem has no switch to do this, get a modem that does. If the problem still persists after bringing up RBBS-PC on an RS-232 interface without a modem or modem cable attached and you are running Page 36 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Microsoft's MS-DOS, bring up RBBS-PC under IBM's PC-DOS. If after bringing up RBBS-PC under IBM's PC-DOS the problem still persists, check that your RS-232 port's cable really is grounded. On AT-like RS-232 interfaces (9-pin), a metal connector on the modem cable is often required. If, after all of the above has been attempted, the problem still persists, try deleting your MESSAGES and USERS files and re-run CONFIG to create new ones. Finally, having exhausted all the above remedies, the system continues to continually re-cycle, you may have an incompatible "clone" PC, incompatible DOS, incompatible modem, and/or a bad copy of RBBS-PC.EXE. IT WON'T ANSWER THE PHONE! This also can be caused by one of the following things: 1.) Phone line is not plugged into the modem. 2.) Modem is not powered on. 3.) Modem is not connected to the communications port that RBBS-PC was told to use. 4.) Your modem is not "Hayes compatible" enough to handle the modem commands described in chapter 13. 5.) Your modem cable does not have PIN 22 connected. RBBS-PC does not require PIN 22 to be hooked up on the RS-232 cable (that's the cable which runs between the modem and the computer) if you specify in CONFIG that RBBS-PC is to answer the phone on zero rings (and that it is not a RING-BACK system). In this setting RBBS- PC will initialize the modem so that the MODEM automatically answers the phone. RBBS-PC's default is that RBBS-PC depends on PIN 22 to know when the phone is ringing and RBBS-PC (NOT the modem) answers the phone by issuing the ATS1? command to determine what ring has occurred and then the ATA command to tell the modem to answer the phone (see chapter 13. In order for RBBS-PC to answer the phone on a specified ring number, the modem must send a "ring-indicator" signal to to RBBS-PC. This is the way that RBBS-PC detects that the phone is ringing. Some computers (i.e. the PCjr's external RS-232 interface) and some modem cables don't have a "ring-indicator" signal. PIN 22 is the ring indicator coming from the modem going to the computer. Just because you bought an RS-232 cable, don't assume that it has PIN 22 connected. The $55 12-pin RS-232 cable sold by many computer stores often may not have PIN 22 connected. For about $18 in parts from Radio Shack you can put together your own RS-232 cable with all the pins connected. Recently a friend of mine paid $14.88 (including postage) for a RS-232 cable with all the pins connected by ordering part number CDB25P-4-S from Jameco Electronics. Jameco Electronics' telephone number is (415) 592-8097. IT LOCKS UP MY SYSTEM! Actually this is probably caused by one of the following things: 1.) The .EXE file generated by the BASIC compiler is incompatible with either the DOS that you are running (i.e. it isn't IBM's DOS) or the other software you load into the system prior to running RBBS- PC via CONFIG.SYS or your AUTOEXEC.BAT file. 2.) You indicated in CONFIG that you were running in one of the supported networks (i.e. CORVUS, MultiLink, Orchid, etc.) but you Page 37 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 aren't. 3.) You are running on a Compaq Deskpro (or using an add-on board that uses the unused IBM DOS interrupt X'7F') and should have used CONFIG to indicate you are using an IBM-compatible PC. 4.) You are using an internal modem that doesn't have the same switch settings as the Hayes 1200 and/or your modem needs to have the result codes turned off when RBBS-PC re-cycles. Set the modem initialization string to: ATQ1E1F1M1X0H0 9.0 PLANNING YOUR USER INTERFACE --------------------------------- RBBS-PC provides each SYSOP the maximum control over what is presented to callers. There are three areas of control: o The menus presented to novice callers. o What is included in the prompt all users get. o What symbol invokes a particular function. 9.1 Menus Shown to Callers -------------------------- The menus in RBBS-PC are external text files that are presented to novice users. RBBS-PC simply displays what is in these files to the callers. Therefore, SYSOPs are free to change the text in these files to whatever they desire. Simply edit the files. However, be sure to use an editor that produces only ASCII text files with no special embedded characters. Most word processing editors are not suitable because they insert special symbols in the file meaningful only to it. WordStar, in non-document mode, is fine, as is the Personal Editor when files are saved with no tabs, and the Program Editor. Most editors used for creating computer programs are suitable. RBBS-PC supports three types of files, which the caller can select using his graphics preference. A file with no graphics has only typable text. ASCII graphics means that all 255 ASCII values display on the caller's screen using the IBM PC display conventions. This allows support for many symbols, such as straight lines, a heart, and many others. Using these conventions, many fancy graphic displays are possible. Last, a use can request color graphics, which means that the caller's monitor supports not only the IBM display conventions but supports ANSI commands for controlling the monitor, which include such things as color as well as special modes like blinking. Using ANSI commands, it is possible to fully control the caller's monitor. One can go so far as to create animated pictures. Menu files are known by their names. The format is XXXXXXXY, where XXXXXXX is the base file name and Y is a one-character addition. Y is nothing for no graphics, G for ASCII graphics, and C for color graphics. RBBS-PC will look for a file based on the users graphic preference and display the graphics version if it exists. Otherwise, the non-graphics file is used. Graphics files have more characters in them and therefore take longer to transmit. Creating them is not easy. However, there are special ANSI and graphics editors which make creating such files much easier. 9.2 Subsystem Prompts Shown to Callers -------------------------------------- RBBS-PC has several configuration options which allow each SYSOP to select the prompts that are presented to callers. They are: Page 38 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 o Whether the section name is shown. o Whether the letters of the available commands are shown. The commands in RBBS-PC are divided into three sections: MAIN, FILE, and UTILITY. Each has a set of commands in them and there are command to move between sections. If the SYSOP elects for the section name to be shown, the command line will read "<section> command", otherwise "Your command". The default is to show the section. RBBS-PC normally prompts a caller with the commands available in each section that the caller has sufficient security to invoke. Each command is a single letter and is shown separated from the others by a comma. These command letters can either be suppressed or not. By leaving them on a SYSOP provides each caller with a terse but helpful reminder of what commands are available to them. 9.3 Commands Available to Callers --------------------------------- All primary commands in RBBS-PC are invoked by single letter commands. An attempt is made to associate the command with the first letter in a word which describes the function, so that the command letter appears to be a short abbreviation for the longer word. The command to invoke reading messages is R. The default symbols that would be shown in the command line for each section are: section|? A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 1 2 3 4 5 6 7 -------|------------------------------------------------------------------- MAIN |? A B C D E F H I J K O P Q R S T V W X 1 2 3 4 5 6 7 | FILE |? D G H L N Q S U V X | UTILITY|? B C F G H L M Q R S T U X | GLOBAL |? H Q X Four commands, ? H Q and X, have the same meaning in every section and are known as "global." The other commands all have unique function specific for the section within which they are invoked. For example, S in the main section stands for S)can messages, but S)ubstring search in files, and S)tatistics on the board and session in utilities. Symbols 1-7 stand for SYSOP functions. RBBS-PC allows the SYSOP to substitute any symbol for any command. Y)ell may be substituted for O)perator page, or Y)our mail for P)ersonal mail. If a blank is substituted, the command is removed from the list and is no longer available. Since there is no V)iew conference command in the main section, a SYSOP may elect to disable the V)iew conference command in the main section by substituting a blank for it. 9.4 RBBS-PC's "Wrap-around" Command Search ------------------------------------------ There is a special option available in CONFIG which gives the SYSOP unusual flexibility in configuring the user interface. A caller is always "in" a section, that is where RBBS-PC looks for a command that the user requests to see whether it is a valid command. The "wrap around" option controls how RBBS looks further for a command when it is not found in the section the caller is in. If a SYSOP substitutes a blank for the V>iew conference command in the main section (as mentioned in section 9.3) and a user enters the V command from the main section, the V>erbose ARC file list command would be what the caller would have invoked. Page 39 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 The basic idea is to look further in other sections, where the search order is MAIN->FILE->UTILITY->GLOBAL->SYSOP and the search is circular, more like ,-->- SYSOP --> MAIN -->---. | | G | L F O I B L A E L | | | `----<--- UTILITY ---<-----' The current section determines only where the search starts. If roll- around is used, the search will go completely around. The real reason that "global" commands are global is that that RBBS-PC always searches after the utility section if a command is not in the current section. SYSOP commands are therefore global for the same reason. The important feature that roll-around supports is that a command with a unique letter works in all sections. Thus W)ho will work everywhere the same if roll-around is enabled. THIS ALLOWS THE SYSOP TO SUPPRESS SECTIONS. In effect, by enabling roll-around and giving each command a unique symbol, all commands become global and there is no effective difference between sections. This allows SYSOPS to make commands available on a single level and makes it unnecessary to "go" to a section before using a command in that section. 9.5 How to Have a Single Universal Command Line ------------------------------------------------ The command structure within RBBS-PC can be made "flatter" without making it absolutely flat. Suppose, for example, that a SYSOP wants callers to be able to do all file functions without going to a files section. In effect, the file functions are available in the main section, or the file section is merged into the main section. All that is needed to do is to eliminate the overlap in command letters between the two sections. The shared letters are D, S, V, and U. V is easy to handle. Since it is not really used in the main menu, just disable V in the main section. D is difficult because both D)oors and D)ownload are entrenched and natural options. One could leave D for the most frequently used function, say download, then use a special but arbitrary symbol like @ for doors. S)earch for substrings could be replaced by F)ind since F for going to F)iles is not longer needed. This could be accomplished by disabling F)iles and substituting F for S in the files commands. The main disadvantage is that experienced users will use F expecting to get into the F)iles section and will get a confusing command. Alienating the old users who will try to use F would defeat the purpose of helping them by making it unnecessary to use F to get the file functions. Better to leave F alone and use a new letter like Z for Z)ippy search. U has to be upload. Note that Quit could still get one to utilities. Using Q;U we can then disable U in the main menu. If three symbols is too much of an exception we could use W for W)rite user preferences. Then we could revise the main menu to read R B B S M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Page 40 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 -- MESSAGES -- -- SYSTEM -- - FILES - - UTILITIES - - ELSEWHERE - E)nter Msg A)nswer survey D)ownload H)elp (or ?) Q)uit K)ill Msg B)ulletins L)ist W)ho's on F)iles (Q;F) P)ersonal Mail C)omment N)ew X)pert on/off G)oodbye (Q;S) R)ead Msgs @)DOORS U)pload W)rite user-pref S)can Msg hdr I)nitial Wel Z)ippy srch (Q;U) T)opic msg scan O)perator Page This menu could be re-written without any apparent sub-sections as R B B S M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~ A]nswer survey G]oodbye N]ew files T]opic msg scan B]ulletins H]elp (or ?) O]perator page U]pload C]omments I]nitial welcome P]ersonal mail W]rite user preferences @]DOORS J]oin conference Q]uit X]pert on/off D]ownload K]ill message R]ead messages Z]ippy search E]nter msg L]ist files S]can messages In order not to confuse the caller by being in a section and seeing only some of the commands we want him to use, the SYSOP could elect not to show the section in the prompt (CONFIG parameter 37) and not to show the commands (CONFIG parameter 38). Callers would see simply "Your command?" as the prompt. This makes the expert mode pretty terse, but that simply means users would spend more time in novice mode before using expert. Now suppose that only a single command line was desired and that the commands from the "Utilities" menu commands were to be added to the above. The "global" H, ?, Q, and X commands already are in the single command line. M for message margin can remain unchanged since it is unique to the Utilities subsystem. In order to accommodate the redundancy of letters that exist by including the Utilities subsystem's commands, the W command for the main message subsystem can be re-enabled and the remote SYSOP's commands be eliminated in order to re-use the numbers. The Utilities subsystem commands B, C, F, G, L, R, and S could then be replaced by the numbers 1 through 9. The Utilities subsystem commands T and U could be replaced by the commands < and >, respectively. This final menu of all RBBS-PC commands could be re-written without any apparent sub-sections as follows and the screen that the would appear to the "novice" users as: Page 41 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 R B B S C O M M A N D S ~~~~~~~~~~~~~~~~~~~~~~~~ A]nswer survey M]essage margin set 1] Change Baud Rate 300-->450 B]ulletins T]opic msg scan 2] Display time of day C]omments O]perator page 3] Set file transfer protocol @]DOORS P]ersonal mail 4] Set type of graphics mode D]ownload Q]uit 5] Set page length E]nter msg R]ead messages 8] Review callers preferences G]oodbye S]can messages 9] Display system statistics H]elp (or ?) U]pload a file <] Toggle users options on/off I]nitial welcome W]ho's on other nodes >] Show the log of callers J]oin conference X]pert on/off K]ill message Z]ippy search L]ist files Your command? 10.0 PLANNING ON HOW TO UNIQUELY IDENTIFY YOUR CALLERS ------------------------------------------------------- All callers need a way to identify themselves and to re-identify themselves on subsequent calls so that they can, for example, read the mail addressed to them. RBBS-PC expects each caller to set a password so that other callers cannot easily pretend to be that caller. Callers are most easily known on bulletin boards the same way they are known in real life - which is usually by first and last name. This is why the default configuration in RBBS-PC uses first and last name to IDENTIFY users. The first/last name is the callers identify or ID. RBBS-PC also allows the SYSOP to identify callers uniquely by something other than their first and last names. Perhaps the SYSOP wants one word alias like AVENGER are to be allowed or perhaps callers must use a preassigned access code (access code, employee number, account number, etc.). RBBS-PC allows ANY FIELD inside the users file to be used for identification. Since there are empty, unused areas in the user file, a SYSOP can even CREATE A NEW FIELD to be used for caller identification. When anything other than name is used to identify users, RBBS-PC still wants callers to specify their names. It just does not use that information to identify them. A fairly common problem on bulletin board systems with large user lists is that two callers can have the same first and last name. A caller discovers this when they are unexpectedly asked for a password on the first call to a new system, indicating that another caller has already used that name. Further, since RBBS-PC is used world-wide many non-english speaking countries (i.e. in Europe, South America, the Far East) have callers with names that have embedded blanks, etc. RBBS-PC alleviates this problem by allowing interior blanks in first and last names. Thus JIM JONES can register as JIM K JONES or JIM JONES SR or JIM JONES III. By allowing ANY field inside the user record to be used to uniquely identify individual callers, RBBS-PC alleviates the basic problem of having two callers with the same name. This additional INDIVIDUATION field is used to distinguish callers with the same ID. The way this works is that callers will have to specify both the identifying and individuation field and both are used to match record in the users file. This individuation field can likewise be a new field created by the SYSOP. For example, the SYSOP can specify that callers be uniquely identified by both their name and their CITY/STATE. Alternatively Page 42 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 the SYSOP can specify that callers are to be uniquely identified by their telephone number, which would be a new field for RBBS-PC to store. 10.1 How to Set Up Identifying and Individuation Fields -------------------------------------------------------- The identifying and individuation fields in RBBS-PC are controlled by parameters in CONFIG. The default is to use the caller's first and last name (combined to be simply name) to uniquely identify a user. The fields available to uniquely identify a caller (other than the caller's first and last name) are designated in CONFIG by the starting position in the users file and length. It is essential therefore to understand WHERE FIELDS ARE STORED IN THE USER FILE. Consult Appendix A for the detailed layout of the user file. RBBS-PC's flexibility requires caution to be exercised when selecting the locations of fields used to identify and individuate, because options can be selected that make no sense. For example, it is possible to specify the user preference field, which means that every time a user changed preferences, such as default protocol, the user would become a different user. There are only two fields in the user file that make sense for identifying users: 1.) first/last name (column positions 1-31), or 2.) a field designated by you as the SYSOP for your RBBS-PC. For a SYSOP-designated field, only 4 choices make sense: none, name (columns 1-31), city/state (columns 63-86), or positions 87-105 in the user record currently "unused." Positions 87-105 of the users file currently unused provides a potential 19 columns to use for special, SYSOP designated fields. However, there is no guarantee that these positions will not be used in later releases of RBBS- PC. Additional fields will be used from the far right. Any SYSOP intending to utilize this area of the users record is safest if the field selected begins in column 87 and is as short as possible. The shorter it is, the more likely there will be room in later releases. For example, 11 columns might be used for telephone number (format 123-1234567). Or 5 columns might be used for account number. When a special field is created, the SYSOP must also supply the prompt to be used with the field, since RBBS-PC has no way of knowing how to describe the field to a caller. The prompt is what is displayed to the caller when asking for the value of the field. RBBS-PC uses the callers first and last name for the "to" and "from" fields for messages even when the users name is not the field used to uniquely identify callers. 10.2 PRELOADING IDENTITIES FOR INSTANT ACCESS ---------------------------------------------- SYSOPs that operate bulletin boards that are open to new callers have no problems giving a new caller instant access -- new callers register, set their identity and password, and are immediately on. SYSOPs that operate bulletin boards that are only available by subscription or who delay access operate differently -- a user must Page 43 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 already know and be able to state identity, individuation, and password in order to get on. To add a new user, the values of these fields must be communicated back to the caller in order for them to have access. To overcome this cumbersome approach, some SYSOPs allow new callers on their system (albeit at a security level so low that the caller can do little, if anything) and simply raise the security level of the caller once the caller has met whatever criteria the SYSOP has set for access to the system. Typically new callers must call back and continue to check to see if their security level has been raised. Systems that do not let new callers on require the SYSOP to enter the appropriate information for each new user, contact the new caller by mail or phone, and let them know how to get on. Both approaches introduce delays to new callers for getting on and additional time, expense and overhead for the SYSOP. RBBS-PC provides a systematic solution to the problem of delayed access for new user! A SYSOP can add a user WITH NO VALUE FOR THE INDIVIDUATION FIELD OR PASSWORD. These fields can be left blank. When a caller logs on with a proper ID and RBBS-PC finds an individuation value or password that is blank, it lets the caller set the value of those fields without requiring a match. Subsequent calls, but not the first, must match the value set for individuation and password. Even though a SYSOP can add a user and leave the password and individuation blank, this still requires that the SYSOP add the user only after an ID is agreed to by both parties. What if this access is still not fast enough? The solution provided by RBBS-PC is for the SYSOP to "pre-load" IDs and give out a pre-loaded ID to the caller for instant access, so that the client does not have to wait even for the SYSOP to add the ID. Since there is no way to set in advance how a user wants to be identified, the SYSOP can set up essentially random account IDs which are difficult to guess and give these out. Callers willing to charge subscription fees on their credit cards over the telephone can be given a valid pre-loaded ID for instant access. The ability of RBBS-PC to use any field for an ID, and let the first call set individuation and password, means that RBBS-PC can support boards where instant access is a critical part of their service. 11.0 RBBS-PC's OPTIONAL AUTOMATIC SUBSCRIPTION MANAGEMENT SYSTEM ----------------------------------------------------------------- RBBS-PC has support built into it for managing access based on the date of the call. The primary uses of this facility are o to make it very easy to control access based on subscription dates. o to give callers a temporary, date limited boost in privileges. The subscription management system dramatically reduces the work necessary for subscription maintenance. After a user is registered, RBBS-PC will AUTOMATICALLY o warn users before their subscription expires o reduce the security of callers whose subscription has expired. In effect, a subscription RBBS-PC can be left on "automatic" pilot and it will operate correctly, without additional effort on the SYSOP's part. The subscription management system can also be used to grant callers a temporary boost in privileges. For example, giving new callers a "free" trial period. Page 44 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Just like cable TV channels that sometimes have a free week of viewing to attract new subscribers by letting them know what they are missing, a SYSOP of a subscription RBBS-PC can set up limited free offers. By setting up a default subscription period of say, 5 days, all new callers can be let onto to see whether they want to subscribe. After 5 days, security drops back down to a more limited level. This "free" period can be made a standing offer, or turned off after a two week period. Or, a user who requests a trial period can be individually added with a short subscription period. Limited trial subscriptions also are an attractive alternative for those SYSOPs that do not give full privileges until after a caller is verified or checked out. These callers are either asked to fill out a registration form or leave a comment, then sometime later the SYSOP decides whether to increase the security level. By letting new users have a short registration period with higher privileges, say 3 days, a SYSOP may choose to give new callers immediate access and minimize the pressure to check the new caller out as soon as possible. The SYSOP need do nothing if a caller cannot be verified. Those that check out get their security raised. This way the many honest new users are not penalized but the prank or dishonest callers can get on only briefly. 11.1 Setting It Up ------------------ The subscription management system is turned on by specifying in CONFIG to limit callers by subscription date. After access is so limited, RBBS-PC automatically records the date of the first call. For old users, this will be the first call made since the subscription date began to limit access. This recorded date is the base registration date. The SYSOP then needs to specify in CONFIG: o A default subscription period (the number of days a new user gets). o A warning period (which determines when callers will get an advance warning that their subscription is about to expire. The warning period is the number of days left needed to trigger a warning.) o The security level expired subscribers get. In the PASSWRDS file, the SYSOP designates: o Different subscription periods for each security level (other than the default security level). This needs to be specified only if a subscription period is desired that will override the default. RBBS-PC determines when the subscription will expire by adding the subscription period to the base registration date. Persons calling after this expiration date are bumped down to the expired security level set by the SYSOP in CONFIG. The subscription periods associated with different security levels is the fourth parameter on a line in the PASSWRDS file (see section 17.3 for more information). For example, to associate a subscription period of 365 days with a security level of 7 having a daily time limit of 60 minutes, the entry in PASSWRDS would be ,7,50,365 Page 45 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 11.2 An Example --------------- A subscription RBBS-PC offers the following levels of service: $3 for 1 year, 60 minutes per day $5 for 2 years, 60 minutes per day new users, 3 days with 20 minutes else 5 minutes This could be instituted by limiting callers by subscription date, limiting the daily time to the session time, setting the default security level to 5, the default session limit to 20, the default subscription period to 3, and expired security to 4. The following lines should then be added to PASSWRDS. ,6,60,365 ,7,60,700 ,4,5, New callers get the defaults: security 5, 20 minutes session time, and 3 days on subscription. After 3 days, the unpaid caller drops down to security 4, which is limited to 5 minutes per day. The SYSOP sets the security of 1 year subscribers to 6 and 2 year subscribers to 7. After the SYSOP configures the system and sets the security level for subscribers, RBBS-PC does all the work of properly managing the callers with no further effort on the part of the SYSOP. 12.0 USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC ---------------------------------------------------- The RBBS-PC.DEF file is created by the CONFIG program and contains the program's default operating parameters and values. When you run the CONFIG program to create RBBS-PC.DEF or to update it, you can change many of these parameters to meet your needs. Certain parameters which control critical operations of the programs are embedded in the RBBS program and should not normally be changed by the system operator. When setting RBBS-PC is set up for the first time, SYSOP's are urged to take the default values generated by CONFIG except for those parameters that are unique to their configuration (i.e. the communication port, etc.). CONFIG.BAS, unlike Gaul, is divided into many parts or screens. They are: Screen Description 1 Global RBBS-PC Parameters (Part 1 of 3) 2 Global RBBS-PC Parameters (Part 2 of 3) 3 Global RBBS-PC Parameters (Part 3 of 3) 4 Parameters for RBBS-PC "static" files 5 Parameters for RBBS-PC "dynamic" files 6 Parameters for RBBS-PC "doors" 7 Parameters for RBBS-PC Security 8 Parameters for Multiple RBBS-PC's and "conferences" 9 RBBS-PC Utilities 10 Parameters for RBBS-PC's File Management System 11 RBBS-PC Communications Parameters 12 RBBS-PC Net Mail 13 New users parameters 14-18 Reserved for future use The user may scroll forward or backward through the 13 screens of parameters in CONFIG.BAS using the PgUp and PgDn keys on the keyboard. Additionally users may go directly to a specific screen by pressing a function key (F1 through F10) or SHIFT and a function key (shift/F1 through Page 46 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Shift F8) corresponding to the page to be selected. To terminate CONFIG, users need only press the "End" key on the keyboard. The compiled version of CONFIG.BAS can be invoked with the command: CONFIG.EXE <config file> The <config file> is an optional name of the configuration file to be created or edited. This assumes that the compiled version of CONFIG.BAS, CONFIG.EXE is on the default disk drive. CONFIG.BAS will write the RBBS-PC definition file, RBBSxPC.DEF to the default drive. 12.1 Global RBBS-PC Parameters (Part 1 of 3) -------------------------------------------- Parameters 1-5 request the RBBS system operator's (SYSOP) name, dual passwords if logging on remotely, and an optional password if logging on locally (i.e. via the Esc key on the PC running RBBS-PC). When logging onto the system remotely, the SYSOP can log on using Password #1 as a first name and Password #2 for as last name, in which case the system will recognize them as the SYSOP and allow all the SYSOP functions to be performed, even as a remote user. The SYSOP name is used to insure that users are not attempting to access RBBS-PC using the SYSOP name hoping to get a higher access level. Attempting to logon using the SYSOP name will result in "LOGON DENIED" and a posting of the attempt in the CALLERS file. If you want to eliminate anyone from logging on as the SYSOP, you can simply reply with a "null" (i.e. a carriage return) to Password #1 and Password #2. The ESC key is used to log on in local SYSOP mode. Parameter 5 allows a password to be required if someone hits Esc on the keyboard of the PC running RBBS-PC before they are considered a local SYSOP. If you enter NONE, no password is required. The SYSOP's default sign-on mode is set by parameter 6 as either EXPERT or NOVICE. Unless you are very familiar with the RBBS-PC CPC14's command structure, the SYSOP's sign-on mode should be NOVICE. The SYSOP can be paged by callers. Parameter 7 allows the SYSOP to set the "office hours" when a user can page the SYSOP. The IBM PC's bell is rather insistent, and these hours should be set to match when you will be within ear-shot of the RBBS-PC. The times are set using a 24-hour military clock (i.e. 10:00 P.M. is 2200 hours). The SYSOP can override these hours by activating the page bell via function key 4 on the keyboard of the PC running RBBS-PC. Because the bell on an attached printer is usually louder than the one built into the PC, the SYSOP can elect to have the printer's bell via parameter 8 whenever the SYSOP is "paged". Parameter 9 allows a SYSOP to not accept calls if the caller is trying to access his system at 300 BAUD. Some SYSOP's believe that 300 BAUD users have a "pre-puberty" mentality and cause more problems (i.e. infantile messages) for the SYSOP than their contributions justify. While RBBS-PC is intended to be as open a system as possible, each SYSOP has the option of electing to lock out 300 BAUD access. Another reason for denying access to 300 BAUD users is when RBBS-PC is running in a multi-tasking DOS environment that does not handle 300 BAUD very efficiently (i.e. like MultiLink). Whatever reasons a SYSOP has for denying access to 300 BAUD users, this option enables the SYSOP to select to do so using CONFIG rather than having to modify the RBBS-PC source code. However, even if 300 baud Page 47 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 access is denied, RBBS-PC can be configured to allow registered users to logon at 300 baud even if new users can't. Parameter 10 allows each SYSOP to see the color text files (i.e. menus, help files, etc.) exactly as the remote user sees them. Obviously the system running RBBS-PC should have a color monitor. More importantly each SYSOP that elects to activate this option should satisfy themselves that the program ANSI.ASM written and copyrighted by David Terry and modified by Dave Staehlin will not harm your particular brand of color monitor or color graphics board. In order to effectively use this option you must have the ANSI.SYS driver loaded on your machine. This can be accomplished by including the statement DEVICE=ANSI.SYS within your system's CONFIG.SYS file. This load's the standard IBM- supplied ANSI.SYS file into your system. If you use an ANSI.SYS other than the one supplied by IBM, you may not see what your remote user sees. CAUTION! - Dave Staehlin indicates the changes he made to the .ASM and .OBJ files reference some color page BIOS - hence, this may not work with a monochrome video card or within certain configurations! Similarly, it may not work with anything other than the standard IBM Color Graphics card and an IBM Color Monitor. Many "plug- compatible" color cards (like Hercules) have been known to burn out a monitor. Any SYSOP who elects this option takes on the SOLE responsibility and risk of determining if the combination of the many components involved in the particular system RBBS-PC is to be run in (the ANSI.SYS, ANSI.OBJ/.ASM code, the color card being used, the color monitor, the BIOS, and the memory configuration) would cause damage to these or any of the other components within the system. To be safe, don't activate this option. If you do activate this option and your system is damaged, you should not expect to be reimbursed for such damage. This option is provided only as a convenience to those SYSOP's who have assumed the sole responsibilities for any results that occur activating this option. Remember, this option need not be activated in order to run RBBS-PC normally! Parameter 11 gives the SYSOP the option of electing to have RBBS-PC automatically take itself off-line if a "disk full" condition occurs. In previous versions, this was not an option. Now, if the SYSOP has a floppy disk for uploads that gets full and everything else is on a hard disk, the SYSOP can keep RBBS-PC from taking itself off-line should the floppy disk get full. Parameter # 12 is the SYSOP'S preference for prompt sounds when input is required. When this is on, both the remote user and the local SYSOP will hear the prompt bell when input is required from the remote user. Parameter # 13 of the CONFIG program asks for the maximum amount of time each user is to be allowed on the system per session. Set the number of minutes to whatever you are comfortable with, but 72 minutes is a good setting for starting up. Subsequently you may have to lower this number once your number of callers increases, in order to keep callers' waiting Page 48 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 times reasonable. This can also be made the maximum time on the system per day. As described elsewhere, each security level can have its own maximum time on the system per session specified. A SYSOP may limit the maximum amount of time any single user can spend on your system each day via parameter 14 of CONFIG. This is helpful if you have a relatively busy RBBS and want to have as diversified group of callers as possible. What this parameter does is to tell RBBS-PC to keep track of the total amount of elapsed time a user is on RBBS each day. Each time a caller logs on, the maximum amount of time that they are allowed on the system is checked against this daily cumulative total. The time remaining in each caller's session is the difference. When a caller exceeds this maximum and tries to log on again, they are told that they have exceeded the allocated time for that day and to try again tomorrow. Parameter # 15 sets the number of months inactivity that must elapse before a user is deleted from the USERS file when the SYSOP "rebuilds" the user file. Parameter # 16 allows the SYSOP to specify the name of the RBBS-PC that is to be displayed when a user first connects with the system and prior to completing the logon process. Parameters 17 through 19 allow the SYSOP to specify the colors desired for the foreground, background, and border. When specifying these options the BASIC manual's section describing the COLOR command in text mode should be consulted. This is useful when running multiple RBBS-PC's and you want a handy way of determine which RBBS-PC it is that you are viewing on the screen. This option is NOT available if the SYSOP has specified a "ring-back" system. Parameter 20 is not implemented in CPC15-1B. 12.2 Global RBBS-PC Parameters (Part 2 of 3) -------------------------------------------- Parameter 21 allows the SYSOP to remind users not only of the messages that might be for them but also messages that they may have left. This should be enough of a nuisance to insure that users do delete some of the messages they have left and help to keep the MESSAGES file to a minimum. Parameter 22 allows the SYSOP to elect to remind users of how many files they have downloaded and uploaded. Parameter 23 allows a SYSOP to remind users every time they log on of the preferences they have selected for such things as file transfer protocol, graphics, nulls, etc. Parameter 24 allows the SYSOP to establish a default page length for users when they log on. A 23 line page length is the default, but the SYSOP can set it to any number between 0 and 255. If set to 0, the user will receive continuously scrolling output. Parameter 25 allows the SYSOP to specify (within the range of 1 to 30) the maximum number of lines allowed in each message. Parameter 26 allows the SYSOP to tell RBBS-PC that files ending in binary file extensions (i.e. .ARC, .EXE, .COM, .OBJ, .WKS, .BAS, or whose second letter of the extension is Q) can not be downloaded unless the user selects XMODEM or MNP. This should eliminate some user problems before they occur. IBM's BASIC interpreter's SAVE command default is to write files in a special binary format (also referred to as Page 49 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 'tokenized') because they require much less disk space. Parameter 27 allows a SYSOP to "reward" users who upload files by adding some multiple of the elapsed time it took for the file upload to the current session time. This should be used judiciously as some users may abuse this by repeatedly uploading COMMAND.COM or some other meaningless file. This extends only the users current session and NOT the elapsed time the user may be limited to per day via parameter 15. Parameter 28 lets the SYSOP force a questionnaire to be answered by all callers, old and new, exactly once. RBBS-PC records in the users record when the required questionnaire is answered so that it will not ask the caller again. Parameter 166 lets the SYSOP reset the flag back to off for all users. This should be done when the SYSOP wants to install a new required questionnaire to be used to survey all callers. In questionnaire is required, this parameter can be specified as NONE. Parameter 29 allows the SYSOP to make the system "welcome" file interruptable. The default is that YES it is interruptable. However, if the SYSOP feels too many people are bypassing it and it contains essential information, the SYSOP can set this parameter to NO (i.e. the user can not suspend or cancel the listing of this file at their terminal with a CTRL S or CTRL K). Parameter 30 is intended to allow the SYSOP to indicate if the system bulletins are to be optional for users when they log on. If bulletins are optional, callers can elect to automatically bypass old bulletins and be notified only when there are new bulletins. RBBS-PC will check the file date of the bulletins and inform the caller which are new, with the option to read all of the new bulletins. If none are new when bulletins are optional, the bulletins will be automatically bypassed. Parameter 31 is designed to allow RBBS-PC to run on some "IBM-compatible" PC's that make use of unused interrupts or on the IBM PCjr. RBBS-PC checks to see if the unused interrupt X'7F' is non-zero. If it is, RBBS-PC thinks that the software product, MultiLink (from The Software Link, Inc.) is present and issues the appropriate MultiLink calls. Obviously if this is not the case, strange and unpredictable things happen which result in RBBS-PC not working. The COMPAQ+ is an example of this syndrome. If running RBBS-PC on an IBM PCjr using an external modem but without an internal modem, the communications port must be opened as COM1 even though RBBS-PC must use the COM2 RS-232 registers for controlling the communications port. Parameters 32-36 let the SYSOP change what symbols are used for each RBBS- PC function by substituting a new letter. Additionally, a space substituted for a command will disable that command, in effect removing it from the system. A natural command to be disable is the V)iew conference command, since it is not implemented. SYSOPs with no DOORS may wish to disable D rather than to confuse users by displaying options not available. All commands displayed to callers in the command prompt will be in sorted order. Parameter 37 allows the section name to precede the command prompt that is displayed when a caller is asked to enter a command. The command prompt begins with <section>, where <section> is MAIN, FILE, or UTIL, if option 37 is selected. Otherwise, the prompt will begin with YOUR. Normally the section in the prompt helps the caller remember where he is, but see Chapter 8 for reasons to suppress the section. Page 50 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Parameter 38 allows the SYSOP to not display the commands to the caller when waiting for the user to enter a command. The default in RBBS-PC is to remind the caller what commands are available by giving a sorted list of the letters used for each command at the end of the command prompt. RBBS- PC shows only the commands available in the section that the caller is in. If the SYSOP chooses not to display the section a user is in, there are more commands available than will be shown in the prompt. Parameter 39 allows the SYSOP to elect to use machine language subroutines (rather than the BASIC routines) for a few of the more commonly used subroutines. These may only be functional within a DOS that is supplied by IBM (rather than Microsoft). Therefore this is optional. If you encounter problems, simply elect to utilize the BASIC routines which are much more likely to be compatible in none "baseline" configurations. In most cases the assembler routines are much faster than their BASIC counterparts, especially in file searches. RBBS-PC supports a "wrap-around" search for valid commands. This means that when a command is not found in the current section, other sections are then searched. The order of search is MAIN->FILE->UTIL. For example, if L is picked when in the main section, where there is no command, the L)ist command in the file section will be executed. Option 40 lets the SYSOP turn this wrap-around search and not execute commands in other sections. Wrap-around is required if the SYSOP want's to have a single command line (i.e. not have the "Utility" and "File" subsystems). 12.3 Global RBBS-PC Parameters (Part 3 of 3) -------------------------------------------- Parameters 41 and 42 determine how callers are going to be uniquely identified when they log on. The default in RBBS-PC is to concatenate first and last name to form name. Parameter 41 lets SYSOPs choose another field as user ID. A field is specified by giving its starting position and length in the user file, and a prompt must be supplied which will be used when asking for user ID. BE VERY CAREFUL CHANGING THIS PARAMETER. Parameter allows the SYSOP to specify a name to be used when prompting the user for the field (i.e. ACCOUNT #). See chapter 8 for additional details. RBBS-PC assumes that name is being used whenever the ID begins in column 1. Parameter 42 lets a field be specified that will be used to distinguish callers with the same ID. Like with ID, the beginning column, length, and prompt must be specified. RBBS-PC defaults to no individuation, which is specified by setting the beginning column to 0. Activating this option forces uses to give additional information when they log on, since both ID and individuation value have to be given. See chapter 9 for details on how to use this option. Parameters 43 through 46 address access control via the automatic RBBS-PC subscription management facilities. For a detailed discussion of RBBS-PC's automatic subscription management facilities, see chapter 10. Parameter 43 means that access will be controlled by subscription dates, and persons with expired subscriptions will get reduced privileges. Parameter 44 is the security level callers get after their subscription expires. Typically this security significantly reduces what a caller is allowed to do. Parameter 45 specifies when callers are to be warned in advance that their subscription is about to expire. This warning is based on the number of days before a subscription expires. Parameter 46 specifies the number of days a new user gets in the subscription period. Parameter 47 determines whether RBBS-PC will ever try to write to a printer. The default is to try to write to a printer, then turn the printing off it there is any problem. On some networks the attempted write Page 51 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 can generate a spooler error that hangs the node. Setting this parameter to "YES" guarantees that nothing ever gets written to a printer. Parameter 48 causes RBBS-PC to play musical themes for auditory feedback on what is happening on a board. This can be important for SYSOPs that are sight impaired. These musical themes are "played" on the speaker of the PC that is running RBBS-PC. The themes are not transmitted to the caller. Parameter 49 is the buffer used internally by RBBS-PC when displaying text files such as menus, directories of files, etc. A SYSOP can set parameter 218 to either minimize memory usage or optimize speed. It is the size of the internal buffer that RBBS uses to real in most text files, including menus. The bigger the buffer, the fewer disk accesses necessary to display the file and the faster the display will be. The default of 128 is the minimum recommended. Increasing this to 512 will increase the speed of text displays. Parameters 50 through 52 are not implemented in CPC15-1B. 12.4 Parameters for RBBS-PC "text" Files ---------------------------------------- Parameter 61 specifies the name of text file that is shown to a user if bulletins are not optional (see parameter 30) or if the user replies "L" when notified of how many bulletins exist. This file should contain a list of the bulletins (i.e. 1-99) and a brief one-line description of the contents of each (e.g. "New Release of RBBS-PC"). Parameter 62 allows a SYSOP to have from 0 to 99 "bulletins." If there are 0 bulletins a user is notified that there are no bulletins. Bulletins should be brief, informative, and timely. I personally think that there should be very few bulletins and that they should be changed often if users are to be enticed to look at them. Making bulletins optional (parameter 30) and bringing them to the attention of the caller on when there are new ones encourages callers to read the bulletins. Parameter 63 provides the SYSOP with the flexibility to make the prefix of the bulletins anything he wants (i.e. BULLET). To this is added the number (i.e. BULLET7 for bulletin number 7) and the disk drive designated in parameter 41 is searched for the bulletin number requested when some asks to see a bulletin. If the file is not found, the user is so informed. If a "graphics" equivalent is found and the user has signed on N/8/1 and requested graphics, the graphics version of the bulletin is displayed (i.e. BULLET7G). Parameter 64 indicates the disk drive and path on which RBBS-PC is to search for to find RBBS-PC's on-line "help" files whenever a user asks for help within a specific subsystem. This is where the help files should be stored. There are some specific help files used by RBBS-PC whose name is simply a help prefix plus a number. The SYSOP may elect to call the prefix something other than the default of "HELP0". Parameter 65 allows the SYSOP to pick up to a seven-character prefix to which the numbers will be appended. This file name is what RBBS-PC will look for on the drive specified in parameter 64 when a user asks for help on-line. As with "bulletins", if a "graphics" equivalent is found and the user has signed on N/8/1 and requested graphics, the graphics version of the help file is displayed (i.e. HELP07G). RBBS-PC identifies help for a particular command by the letter of the section and the letter of the command, plus an extension for the help Page 52 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 files. The extension "HLP" is the default but option 66 lets the SYSOP set this to whatever desired. Parameter 67 is the name of the file that is displayed to a caller should the caller ask for help when requested to categorize a file that has been upload. RBBS-PC' File Management System can be configured to minimize the SYSOP's activities by allowing users to categorize the files that are uploaded. This file should list the names of the categories that an uploader can select. It should be stored on the same drive and path as the other help files. The category selected will be validated to make sure that it is in the list in DIR.CAT or that a valid category file with that name exists. The appropriate category code will be written out to the shared FMS directory, or the entry for the upload will be appended to the category file. Parameter 68 allows the SYSOP to select any name for the text file that new users see when they first log on and before they "register" themselves in RBBS-PC's USERS file. A user sees it once and only once during his first session. It can contain anything you want it to, but a brief explanation of your Board's purpose, "rules", etc. might be appropriate. Parameter 69 allows the SYSOP to select any name for the text file that each user sees EVERY time AFTER they log on. Keep it brief! RBBS-PC will look for a "graphics" equivalent if the user qualifies for graphic displays (i.e. it will display the file HELLOG in lieu of HELLO). The file named "PRELOG" will be displayed as soon as carrier is detected and BEFORE a user can log on. It is displayed immediately after the name of the RBBS-PC is shown (see option 16) and providing it: 1. has the name PRELOG and, 2. is on the same disk drive as the WELCOME file. SYSOP's should use "PRELOG" to convey such information as whether real names are required, 300 baud users will automatically be denied access, etc. Parameters 70 through 75 focus on the text files that RBBS-PC displays to novices as "menus." Menu files shown to novices tend to be frequently accessed. Systems that do not have disk caching should consider putting menus in a RAM disk in order to cut down on the wear and tear of your disk drives. Parameter 70 allows any valid name to be given to the text file containing the commands allowed those with SYSOP privileges. Parameter 71 allows the SYSOP to specify the name of the text file containing the menu of commands available to those in the main "messages" subsystem. Parameter 72 allows the name of the text file containing the menu of commands available to those in the "files" subsystem to be any valid name. Parameter 73 allows the name of the text file containing the menu of commands available to those in the "utilities" subsystem to be any valid name. Parameter 74 is the name of the text file listing the names of the conferences that are available. Conference names must be seven-characters or less, in all caps, and cannot have any character to the left or right of Page 53 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 the name except possibly a space. The SYSOP must already have pre- formatted the messages and users files associated with the conferences (see chapter 19.0). Parameter 75 allows the user to specify the name of the text file containing the list of the questionnaires, surveys, or forms which callers can fill out or answer. The scripting support built into RBBS-PC allows the SYSOP to construct a series of questions to be presented to the caller and save the answers. Questionnaire names must be eight characters or less, in all caps, and cannot have any character to the left or right of the name except possibly a space. Of course, the actual file name for the script has an extension of ".DEF". Thus, a questionnaire called SURVEY would appear in the text file identified in Parameter 75 as SURVEY, preceded and followed by at least one blank character, and exist as a file named SURVEY.DEF. Parameter 76 is the name of the text file listing names that the SYSOP considers inappropriate. This file is used when a new user signs on. The new users first and last name are each individually checked against the names in this file. The format of this file is as follows: <name>, An example of such a file would be: KILLER, MAN, THE, DOC, DOCTOR, DEATH, All names should be UPPER CASE! If you create the file using IBM's standard DOS text editor, EDLIN, each line should end with a comma. If you create the file using COPY CON, each line should end with a carriage return (i.e. the "enter" key). The last line (when using COPY CON) should end with a Control Z, F6, and then carriage return. BASIC will treat either a comma or a carriage return as a field delimiter. You need a field delimiter following each of the names. If the above file existed, any new user who logged and used the following names would be denied access: Byte Killer Kilo Man Doctor Death PC Doctor The Best 12.5 Parameters for RBBS-PC "system" Files ------------------------------------------ Parameter 81 allows the SYSOP to specify the file name for the file used by RBBS-PC to hold the messages on the bulletin board. This file can NOT have an extension because RBBS-PC appends the extension ".BAK" to the file name when "packing" the messages file. RBBS-PC keeps a profile of each user who logs on in a "user record" (see Appendix A for a layout of this record). Parameter 82 allows the SYSOP to specify the file name for this file. This file can NOT have an extension because RBBS-PC appends the extension ".BAK" to the file name when "packing" the users file. Page 54 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Instead of leaving a "message", a user may leave a comment for the SYSOP that is readable only by the SYSOP. Parameter 83 allows the SYSOP to specify the fully qualified name for the file used by RBBS-PC to store users' comments. Parameter 84 allows the SYSOP to have comments recorded as private messages to him in the main messages file providing there is any room. This allows replies to comments to be done much more easily. RBBS-PC maintains a log of user activity on a "callers" file. It contains information on the date, time, communications parameters of who logged on; what they uploaded or downloaded; and any security violations or errors that were generated. Parameter 85 allows the SYSOP to specify the fully qualified name for the file that RBBS-PC uses for this log. If parameter 86 is selected, additional items of information are included in the CALLERS file: 1) "Connect not completed" 9) "Left comment at time" 2) "Sleep disconnect" 10) "Logged off at time" 3) "Caller changed name/address" 11) "Carrier dropped at time" 4) "Newuser" 12) "Message # xxxx left at" 5) "Bulletin# read" 13) "Read Messages ..." 6) "SYSOP initiated Chat" 14) "Answered questionnaire xxx" 7) "Entered Conference name" 8) "Time limit exceeded" It should be remembered that for each occurrence of the above, the CALLERS file will increase by 64 bytes. Unless you either have a hard disk or are willing to frequently maintain your system in order to leave enough free space on the disk drives for new files, this option should NOT be activated. Parameter 87 has not been implemented in CPC15-1B. 12.6 Parameters for RBBS-PC "Doors" ----------------------------------- Parameter 101 allows the SYSOP to enable RBBS-PC to exit and return to the system (i.e. DOS). You will also be asked if you will be running "doors" with MultiLink. If you reply yes, you can they choose what type of terminal MultiLink is to assume the user is using when MultiLink receives control from RBBS-PC. See the MultiLink manual for the various terminal types. If you choose terminal type zero, MultiLink will not be given control of the communications port when RBBS-PC exits to the "door." Use this if your application is coded to control the communications port. The batch file out of which RBBS-PC is invoke should then check to see if a "door" is to be invoked. A "door" is simply a batch file that the SYSOP has created which RBBS-PC users are allowed to exit to and which will then take control of the remote users communication port. Parameter 102 allows the SYSOP to specify the fully qualified file name of the menu that lists the names of the "doors" available to users. RBBS-PC checks this file to verify that the name of the door that the user requested is in the doors menu (see chapter 16). A door name in the menu must have 8 or fewer characters, be in all caps, and the only character that can occur immediately before and after the name is a space. Parameter 103 allows the SYSOP to specify the fully qualified file name of the file that RBBS-PC is to use when dynamically building the .BAT file that invokes the "door" selected by the user. The batch file that invokes RBBS-PC must contain an "IF" to check if this file exist whenever RBBS-PC Page 55 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 terminates and (if it exists) to execute it (see chapter 15). This is also the same file name that is used when the SYSOP exits to DOS. When a door finishes RBBS-PC is re-invoked. Parameter 104 allows the SYSOP to specify the fully qualified file name of the .BAT file that should be used to re-invoke RBBS-PC (see chapters 15 & 16). This is also the same file name that is used when the SYSOP returns from exiting to DOS. Whenever you exit to a "door" or to DOS (via the remote SYSOP's function 7), RBBS-PC needs to know where to find COMMAND.COM. In a network environment with several PC's the COMMAND.COM's may be different for each PC. Parameter 105 allows the SYSOP to specify for the each copy of RBBS-PC a disk drive on which to find the COMMAND.COM appropriate for that copy of RBBS-PC. Parameter 106 allows the SYSOP to elect to redirect I/O to communications port when executing a program external to RBBS-PC either via the standard DOS "Change Console Command" (CTTY) or the special characters < (for input) and > (for output). Parameter 107 allows the SYSOP to select how RBBS-PC is to invoke those external programs such as communications protocol drivers for file transfers (i.e. Kermit) to fulfill its own functions. There are two ways to execute these other programs: 1. EXITing RBBS-PC and invoking the other program via a .BAT file that RBBS-PC builds dynamically, or 2. SHELLing to the other program while RBBS-PC remains in memory. EXITing RBBS-PC allows other BASIC programs to be run as external programs to RBBS-PC, conserves memory, and allows all of RBBS-PC's features to be active in computers with only 256K of memory. The "price" that is paid is that upon returning from the externally called program RBBS-PC's .EXE file must be reloaded into memory. SHELLing prohibits other BASIC programs to be run as external programs to RBBS-PC, consumes memory because RBBS-PC remains in memory when the other program is running, and requires 292K of memory (under DOS 3.2) to activate all of RBBS-PC's features. However, SHELLing does eliminate the need to reload the RBBS-PC.EXE file each time. Option 107 lets the SYSOP specify how other programs will be invoked. See option 213 as well regarding the external protocol drivers. 12.7 Parameters for RBBS-PC's Security -------------------------------------- Parameter 121 specifies the minimum security level users need in order to log onto RBBS-PC and parameter 122 specifies the security level assigned to new users. If the security level assigned new users is less than the minimum security level to log on, no new users can logon on. This means that no new users are allowed and access is limited only to pre-registered users. Since one of RBBS-PC's two objectives is to facilitate the exchange of information, every RBBS-PC SYSOP is urged to not entirely deny new users access. The chapters on RBBS-PC's extensive security features and subscription management detail the ways in which a SYSOP can control access to his RBBS-PC without having to deny access to new users. Parameter 123 allows you the minimum security level a user must have to be considered an "assistant" SYSOP by RBBS-PC to be specified. Even if a user has a high enough security level to see the SYSOP's menu and execute some or all of the SYSOP commands, the user will not be treated as a SYSOP (i.e. Page 56 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 allowed to see the files upload/download when viewing the CALLERS file) unless the users security level is equal to or greater than that specified by this parameter. Parameter 124 specifies the name of the file that contains a list of file names that CANNOT BE DOWNLOADED (even if they are on the disks that are available for downloading) unless the user supplies a password and/or is at a specific security level. If you want to have no file security at all, just put no file names in this file. If you include a password with a file name all users (including one with SYSOP privileges) must be able to give the password in order to download the file. For a more detailed description of this file and how it works, see the section entitled "How to Implement the Security for Download Files." Parameter 125 prevents the SYSOP menu from being displayed (even if the user has a security level of a SYSOP as specified in option 123) unless the user is also at this security level. Parameter 126 allows the SYSOP to set the minimum security level a user must have to exit RBBS-PC via a "door". This security level must be equal to or higher than the security level for the "D>oor" command (see Parameter 129). Parameter 127 allows a maximum number of security violations (i.e. attempts to download protected files) before the user is logged off and locked out. Parameters 128 through 132 allow the SYSOP to set up the security levels required to issue the commands in the SYSOP, Main Menu, File Subsystem, Utilities Subsystem (respectively), and global commands. All the commands in each area can be given the same security level or, optionally, a specific command can be given a unique security level. Parameter 133 specifies the file name which contains the privileged group passwords that allow users to change temporarily their security, time on the system, etc. -- if the SYSOP has set it up that way. Callers shift to a group password by changing passwords. If the password they select is found in the file containing the privileged passwords, their private logon password is unchanged and they receive the security level and/or time limit associated with the group password. If you have no group passwords, just put nothing in this file. For a more detailed description of this file and how it works, see the section entitled "How to Implement the Password File." Parameter 134 allows the SYSOP to specify the maximum number of times users can change their passwords in a given session. This prevents a caller from "fishing" for special passwords. Parameter 135 is the minimum security level required in order for users to change temporarily their security or time on the system via privileged group passwords. If users do not have the minimum security level to temporarily change their password, ALL password changes that they make will be permanent -- even if the password they select is in the temporary password file named in parameter 112 of CONFIG! Parameter 136 allows the SYSOP to specify a security level that has the privilege of overwriting files (i.e. files that already exist) when uploading. When the SYSOP "purges" the USERS file, all users who have not signed on within the number of months specified in parameter 16 are deleted from the Page 57 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 file with the exception of those who have been "locked out" and those whose security level is equal to or greater than that specified in parameter 137. Parameters 138 through 140 are not implemented in CPC15-1B. 12.8 Parameters for Multiple RBBS-PC's -------------------------------------- RBBS-PC allows multiple RBBS-PC's to run in the same environment/network and share many of the same files. If you ever plan to do this or if you are going to do this, set this number to the MAXIMUM number you ever envision running. Up to 36 RBBS-PC's can share the same files. Different environments have different maximum number of nodes that they can effectively support. Parameter 141 allows you to specify the maximum number of RBBS-PC's that the MESSAGES file should be initialized for. Parameter 142 allows the SYSOP to designate the type of environment that multiple copies of RBBS-PC will be sharing files in. This is necessary so that RBBS can use the mechanism that is appropriate to the specific environment when sharing files. RBBS-PC currently can handle the following environments for multiple RBBS-PC's: 1. MultiLink (The Software Link, Inc.) 2. OmniNet (Corvus) 3. PC-Net (Orchid) 4. DESQview (Quarterdeck Office Systems) 5. 10 Net (Fox Research) NOTE: Many manufacturers utilize Orchid's network conventions. As an example, AST and Alloy are both vendor's whose "network" is .EXE file- compatible with Orchid's (i.e. "An Orchid by any other name is still an compatible their network is with those supported by RBBS-PC. Some local area network environments are not designed to have applications constantly branch back to the beginning and re-open already open files. If you are in this environment or simply want to run external programs after a user logs off or RBBS-PC recycles, parameter 143 allows you to elect to do this. If you specify "internal", RBBS-PC will function as it currently does and branch back to its beginning. If you specify "system", RBBS-PC will exit to DOS and (if you are running RBBS-PC out of a .BAT file) you can then automatically invoke any other "housekeeping" programs you want before re-invoking RBBS-PC. It should be noted that this will add a considerably delay to RBBS-PC's recycling time as RBBS-PC will have to reloaded back into memory every time it recycles. Like the MESSAGES file, the USERS file must also be static in length for RBBS-PC. Parameter 144 allows the SYSOP to set the size of the USERS file. RBBS-PC automatically keeps track of the records available for use in this file and does the necessary "housekeeping." To do this RBBS-PC requires the USERS file size (i.e. the number of records in it) to be a power of 2. When the USERS file get full (i.e. all its records are used up) and the SYSOP neither "packs" it nor increases the size of the file, no new users will be able to be added to the users until one of these two events occurs. Parameter 251 lets new users get on even if the users file is full. RBBS-PC requires that the "Messages" file be static in length. It automatically keeps track of the next record available and does the necessary housekeeping to maintain the integrity of the file. Parameter 145 allows the SYSOP to set the size of this file. CONFIG.BAS will automatically determine what size the current file is and will reformat a pre-CPC12-3A MESSAGES file if it finds one. If you do not increase the size of your existing MESSAGES file, no one will be able to leave any new Page 58 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 messages. Similarly, when the MESSAGES file get full (i.e. all its records are used up) and the SYSOP neither "packs" it nor increases the size of the file, no one will be able to leave a message until one of these two events occurs. The minimum size of the MESSAGES file is equal to 1 (The "checkpoint" record) plus the maximum number of concurrent RBBS-PC's ("node" records) plus the maximum number of messages allowed multiplied by 5 (each messages is assumed to average five 128-byte records) Therefore, if option 141 of CONFIG where 12 and option 145 of CONFIG where 50, the minimum number of records that could be specified for option 125 would be 1 (The "checkpoint record) + 12 (The number of "node" records) +250 (50 messages x 5 128-byte records each) ---- 263 records for the MESSAGES file Parameter # 146 lets you set the maximum number of messages that the SYSOP will allow on the system at any one time. The number will have to be based on the size of the average message on your bulletin board. Most messages require about 600 bytes on the average. The absolute upper limit on the number of messages is 999. If you specify 250 messages, you can expect that the MESSAGES file will be preformatted to more than 160K in size. Parameter # 147 allows "conference" files to be maintained. A "conference" consists of a message file and, if a "private" conference, a corresponding users file. The name of the conference can be anything that the SYSOP selects but can not be longer than 7 characters. The message file's name for a conference consists of the conference name plus the characters "M.DEF". The user file's name associated with "private" conferences consists of the conference name plus the characters "U.DEF". Parameter # 147 allows the SYSOP to create, expand, or contract either or both of the files associated with a "conference." This occurs ONLY when the SYSOP "ENDs" the CONFIG session by pressing the key marked END. Parameter # 147 allows the SYSOP to perform all the functions on page 8 of CONFIG on the conference that was named/selected with Parameter # 147. For a further discussion of "conferences" see chapter 20. 12.9 RBBS-PC SYSOP Utilities ---------------------------- The message file contains all messages for the RBBS-PC system. As messages are killed they are only flagged as inactive. Parameter 161 should be used periodically to recover the space occupied by the killed messages. After completion, only the text of active messages will be present and the old file will remain on the system with the name of MESSAGES.OLD. Also, you will need enough free disk space for the MESSAGES and MESSAGES.BAK files when packing the MESSAGES file or the packing cannot be performed. If enough space is not found the packing will terminate abnormally and the MESSAGES file will be recovered. Parameter 162 removes deleted users and users who have not been on the system within the number of months specified using parameter 16 in CONFIG. You should have enough free disk space for USERS and USERS.BAK or the rebuilding will terminate abnormally (the USERS file will be restored). It is important to note that beginning with CPC12-5A, the USERS file is no longer a random file that is accessed sequentially but now is a random file that is accessed directly. When a user logs on RBBS-PC "hashes" the users Page 59 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 name to find the users record directly in the USERS file. That is why the USERS file's size is a power of 2 (i.e. 256, 1024, etc.). This allows users to log on much more quickly to RBBS-PC's that have a very large number of users. Parameter 163 will display the message headers of all messages, active and killed, that are present in the message file. This is left over from one of the many "debugging" stages of RBBS-PC prior to CPC09. Following the policy of making all changes "additive", this function has been retained. It may help some SYSOP's recover from disk hardware failures. Parameter 164 permits messages to be renumbered sequentially starting from a specified message using whatever starting number you wish. Please note that there is not much error checking to be sure that the new numbers do not duplicate those of lower numbered active messages. When complete, the next message to be created will be the next higher number from the resequence. Unpredictable results will occur if a SYSOP creates messages with duplicate numbers! Parameter 165 goes through the MESSAGES file and reconstructs the chains that link the messages together. MESSAGES files that have "blank" messages or abbreviated messages (i.e. some lines of text are missing) can be repaired with this facility. Parameter 166 allows the SYSOP to require all users (old and new) to answer the required questionnaire whose name was specified in parameter 28. Parameter 167 allows the SYSOP to determine whether the format of the RBBS- PC directory of files being used by the RBBS-PC File Management System (FMS) to conform to the exact fixed format required by the FMS (in case the text editor used by the SYSOP to edit the file inserted tabs or shorten lines that had trailing blanks at the end of them). 12.10 Use of DOS Subdirectories ------------------------------- Parameter 181 specifies the letter of the single drive available that this copy of RBBS-PC can write uploaded files to. When a file is uploaded, the file specified by CONFIG parameter 182 will be automatically appended with the file name, file size, date of upload, and short description as specified by the user. Parameter # 182 of the CONFIG program asks for the name of the text file to be used as an RBBS-PC "directory" of files into which the file name, file size, and file description of uploaded files can be recorded. The default name is 99.DIR and it must be on the drive/path specified in parameter # 183. Parameter 183 specifies the drive/path were the upload directory is to be found. Parameter 184 specifies the letters of the drives from which files can be downloaded. The order in which they are specified is the order in which the drives will be searched. If the order is BAC, then drive B will be searched first for the file, then drive A, and finally drive C. While there can be duplicate files on each of the drives, the first file found will be the one downloaded to the user. Parameter 185 allows the SYSOP to indicate that DOS subdirectories are to be used by allowing the number of DOS subdirectories to be used for downloading to be specified (0 to 9999). This number is equal to the number of DOS subdirectories to be used for uploading (0 or 1) plus the Page 60 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 number of DOS subdirectories to be used for downloading. Parameter 186 allows the SYSOP to indicate the DOS subdirectory to which uploads are to be written. RBBS-PC will prepend the upload disk drive to it (see parameter 181) and append the upload file name after it when uploads are written to disk. Parameter 187 allows the SYSOP to indicate that DOS subdirectories are to be used when searching for files on downloading. A valid download drive followed by a colon, a reverse backslash, and the subdirectory name that is to be searched must be entered. If the root directory is also to be searched, just enter a valid download drive followed by a colon. Each download disk drive is searched for only those subdirectories that were specified as existing on that specific drive. If two download DOS subdirectories are specified (A:\TEST1 and B:\TEST2) and two download disk drives for parameter 184 (A and B), the search for a download file will be in the following order: A:\TEST1\filename B:\TEST2\filename It is possible to have the same subdirectory name on different download drives. Each would have to be individually specified (A:\GAMES and B:\GAMES If they where, the search for a download file would be as follows: A:\GAMES\filename B:\GAMES\filename Parameter 188 is only functional if parameter 185 is greater than 0. This parameter allows the SYSOP to list, change, add, or delete the DOS subdirectories to be used for either uploading (parameter 182) or downloading (parameter 187). CONFIG does NOT actually create or delete such DOS subdirectories -- that's up to the SYSOP to do using the standard DOS commands. Parameter 188 simply allows the SYSOP which DOS subdirectories will (or may) exist when RBBS-PC is running. Parameter 189 allows the SYSOP to specify the extension that RBBS-PC's "directories" of files are to have. See chapter 13 for a description of RBBS-PC's "directories" of files.-- they have no relation to DOS 2.x and above subdirectories! Most SYSOP's categorize the files that are available for downloading into general groups (games, utilities, etc.). The default is "DIR". This extension is also used as the prefix of the directory of directories that is presented to callers when they ask for a list of the directories available (DIR.DIR). Option 190 allows the SYSOP to exclude the primary directory (DIR.DIR) from the search done by the New command. If you have multiple directories (i.e. RBBS.DIR through BASIC.DIR), any dates in the primary directory would not be of files. The "New" command (as in "What new files have been put on the download directories since I was last on?") search each line of each file whose extension is DIR for a date field. Since the first level directory is normally a listing of the other directories and their general subject areas, it is advisable to omit the first level directory from the "New" command. Descriptions of files uploaded are always appended to the upload directory. Parameter 191 allows the description to be appended to another file. This could be, for example, a list of all files on the system, or the basis for a bulletin reviewing the uploads. Page 61 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Option 192 is how the SYSOP declares that there is a shared FMS directory. Leave it blank if there is none. Chapter 14 discusses in detail the advantages of using this directory, which has a different structure from other directory files. This file must be in the drive/path for directories. Users who upload can classify uploads into a category if their security is at least as high as the level specified in parameter 193. This option can save the SYSOP considerable time. If the uploader cannot classify the upload, it goes only to the upload directory and uses the default category code if written to the FMS directory. If you do NOT want users to categorize the files that they upload, independent of whether or not you are using FMS, simply set the CONFIG option 193 to a security level higher than any user can obtain. If the uploader cannot classify the upload, it goes only to the upload directory and uses the default category code if written to the FMS directory. If you DO want users to categorize the files that they upload you must follow these four steps: 1. Set CONFIG option 193 to the security level of the U>pload command. 2. Create a help file to show users when they are asked to categorize an uploaded file that might look something like: Category Category Description Code Name 1 Utilities General Utilities 2 Games Games 3 RBBS-PC RBBS-PC files 4 RBBS-UTIL Utilities for RBBS-PC 3. Set CONFIG option 67 to the name of the file that you created for step 2 4. If, and ONLY if, you are using the FMS, create a second file in the format described in section 14.0 for option 196 and set option 196 to the name of the file created in this format. Set parameter 194 to "YES" if there are no directories other than the FMS directory. That increases the speed of RBBS-PC because it does not look for additional directories. If you do not have a shared directory or have a hybrid system with some physically distinct directory files, set this parameter to "NO". Parameter 195 is the default category code for uploads. This parameter is how uploads get classified in the FMS directory if the uploader cannot provide a classification. To make all new uploads private and viewable only by the SYSOP (until the SYSOP reviews the files and changes the classification), set the default code to "***". The default is "UC" for UnClassified. Parameter 196 is the name of the text file which tells RBBS-PC what categories are included in the shared FMS directory. The format of the file is "<category name>","<category codes>","<category description>" Page 62 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 For example "BASIC","BPG","BASIC Programming" means that callers know the category as BASIC, its code in the FMS directory is "BPG", and the category is to be described to callers as "BASIC Programming". See chapter 14 for details on how to set up this critical system file. Parameter 197 is only meaningful if the RBBS-PC File Management System (FMS) has been enabled via parameter 192. RBBS-PC will scan this file for the latest uploads. When a caller logs on, RBBS-PC will determine how many files are new since the caller last logged on, up to a maximum of 23. By setting option 197, the caller is offered the chance to immediately review these new files for downloading, if the caller has sufficient security to download. This happens before the bulletins or messages are reviewed. RBBS-PC's that emphasize software exchange may want to enable this option, others may not want to give the caller a chance to download the new files until after bulletins and messages have been reviewed. Parameter 198 sets the maximum length of the description that can be given to an uploaded file. RBBS-PC can be configured so that those who upload files can provide a description of the file they upload. This description informs others what the file does and helps them decide whether they want to download the files. The maximum length of the description can be set to any value between 40 and 46. WARNING: this option will not change the length of existing directories. Parameter 199 controls who can view new uploads based on security level. This works differently, depending on whether type upload directory is the FMS directory and is stored other than in the searchable directories. 1.) If the upload directory is not in the drive/path of the searchable directories, it will be viewable if and only if the callers has a security at least as high as the minimum to view new uploads. 2.) If the upload directory is not the FMS directory but is stored in the same drive/path as it, it will be viewable. 3.) If the upload directory is the FMS directory, the minimum to view applies only to uploads with the default category code. Parameter 200 specifies where all directory files must be put, except possibly for the upload directory. Only in this DOS directory does RBBS-PC look for RBBS-PC directory files, with the sole exception of the upload directory when the caller's security level permits the upload directory to be viewed (see parameter 199). 12.11 Communications Parameters ------------------------------- Parameter # 201 requests the user to specify the communication port that RBBS-PC will use. Because the BASIC language can only support COM1 and COM2, RBBS-PC can only support COM1 and COM2 for remote access (i.e. via a communications port and a modem). However, RBBS-PC does accept COM0 as a parameter. This allows RBBS-PC to run on a PC without using a communications port or modem and still appear to the PC user as if they were accessing RBBS-PC remotely. This "workstation" feature can allow RBBS-PC to be used in a local area network environment where each of up to 36 PC's can access the central RBBS-PC system (on the LAN server) and use Page 63 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 RBBS-PC for electronic mail within the LAN. Alternatively this "workstation" mode can be used to teach users how to access RBBS-PC in a classroom environment without requiring telephone access. Parameter 202 allows the SYSOP to specify the number of seconds that RBBS- PC should wait after initializing the modem with a "reset" command. Most modems require only 2 seconds, however some may require much (MUCH) longer. If the 2 second default is not sufficient consult with your modem vendor and try different settings. Parameter 203 allows the SYSOP to specify how long to wait prior to issuing a modem command. This is most useful when you have configured RBBS-PC to only issue commands between rings and want the modem to "settle down" after a ring has ended. The default setting is one second. If you find that 2400 baud calls are improperly connected at 1200 baud, increase the wait. Some modems take longer to connect at 2400 than at lower speeds. Parameter 204 specifies the number of rings to wait before answering the phone. Specifying zero rings means that RBBS-PC will answer the phone as soon as it rings. If you specify the number ONE, RBBS-PC will wait for the phone to ring and then instruct the modem to answer the phone. This is the default setting and requires that the modem be capable of indicating that the phone is ringing (i.e. provide the "ring indicator" signal) and that the modem cable have PIN 22 connected at both ends. Specifying a number equal to ZERO (and not specifying "ring-back") means that RBBS-PC will initialize the modem to automatically answer the phone (independent of RBBS-PC) and RBBS-PC will simply wait for carrier detect to occur. This is NOT RECOMMENDED. However, if your non-Hayes modem simply is incapable of indicating that the phone is ringing or your modem cable does not have PIN 22 connected, this is the option you will have to elect. If this option is selected, you are not allow to drop into DOS remotely (either through a "door" or via the SYSOP's function 7). If we allowed this and your were inadvertently disconnected the next person to dial would be connected to wherever you where because the modem (not RBBS- PC) is answering the phone. If you specify a number greater than 2 means that RBBS-PC will either: 1. wait until the specified number of rings to answer the phone, or 2. answer the next call after the current one after the specified number of rings specified provided that the next call comes within 45 seconds after the first call stops ringing the phone. This mode is called RING-BACK. Specifying a number greater than one is useful only when a single phone line can receive both voice (i.e. callers who wish to speak with the SYSOP) and data calls (i.e. for RBBS-PC) on an unscheduled basis. In this type of environment (i.e. a random mix of voice and RBBS-PC calls), there are two ways a SYSOP can set up RBBS-PC so that RBBS-PC can automatically determine if the call is for the SYSOP or for RBBS-PC. First, the SYSOP can establish the rule with the callers that if unable to personally answer the phone, then RBBS-PC will answer the phone after it rings the number of times specified in option 9. Callers can let the phone ring and (if it is not answered by a person within some agreed upon number rings) know that it will be answered by RBBS-PC. This is useful to those who may have either hearing or speech problems and are unable to use the Page 64 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 telephone conveniently for voice communications. A second approach is the more classic, "ring-back" approach. RBBS-PC can be told to NEVER answer the first call (it can ring forever!). However, should the caller WAIT A MINIMUM OF 12 SECONDS (a Hayes restriction) and call back no later than 45 seconds after the last ring of the first call, RBBS-PC will answer the call after the number of rings indicated in parameter 9 provided that the number of rings is set to between one and five. If callers want to make a voice contact, they can simply call and let the phone ring until it is answered. If you have a dedicated line for your RBBS-PC (either full-time or on a scheduled basis), parameter 9 should be set to ZERO. Option 205 provides the SYSOP with the capability of selecting ANY modem commands appropriate for the modem being used -- not just the default Hayes commands RBBS-PC would normally use. Before the default RBBS-PC standard Hayes commands are changed, you should thoroughly understand the modem that your are using and the modem commands, as used by RBBS-PC, that are described in section 13. Option 206 allows MNP to be optional within RBBS-PC. REGRETTABLY, this option can not be selected with version CPC15-1B. This is because it was not possible to resolve the linkage incompatibilities between the new compilers and the MNP library and RBBS interface prior to the release of CPC13-1A. Every effort is being made to correct this particular problem. Some SYSOP's may not wish to provide their users with the choice of MNP protocol (especially if they are employed by a company that has a competing protocol). RBBS-PC's features and growth are designed to be "additive." This parameter allows each SYSOP to decide if MNP protocol is to be available for file transfers. Microcom's error-free protocol, MNP, is available for file transfer beginning with version CPC12-4A of RBBS-PC. Option 207 allows the SYSOP to tell RBBS-PC either to wait to issue commands in-between rings or to issue modem commands without waiting. Some modems cannot both handle the telephone ringing and accept modem commands simultaneously. Other modems, like the Hayes, can handle such simultaneous demands. For these later (i.e. Hayes, Prometheus, Multi-Tech, etc.) this option should be set to "NO." Some 2400 baud modems (like the Hayes) MUST be opened initially at 2400 baud because when they automatically answer the phone they can only "bump down" when automatically detecting baud rate (i.e. from 2400 down to 1200 down to 300). Parameter 208 allows the SYSOP to select the baud rate at which RBBS-PC is to open the modem at initially. The SYSOP can select the number of seconds RBBS-PC will allow a user to be "idle" (i.e. not sending or receiving data) via parameter 209. Parameter 210 allows the SYSOP to indicate if a "dumb" modem is being used (i.e. one that will answer the phone and automatically detect the caller's baud rate if it is the the modem was opened for). Selecting this means that no modem commands are written to the modem. If the SYSOP has a non-Hayes modem (i.e. one that will not recognize Hayes commands and will not return Hayes responses) that will only "auto-answer" the phone, parameter 210 allows the SYSOP to so indicate to RBBS-PC by selecting "dumb" modem. Typically this would be some communications network (i.e. TymnNet) or local area network that supplied a simple RS-232 interface. Selecting this option causes RBBS-PC to Page 65 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 1. Issue no Hayes commands, 2. Depend on no Hayes-like responses, 3. Control the interface with the Data Terminal Ready (DTR), 4. Assume somebody has called whenever Carrier Detect (CD) is detected, and 5. Assume that whomever calls is at the baud rate selected in CONFIG parameter 38. The Hayes 2400 baud modem has no hardware switches. It's remembered, permanent settings can be set only through software. Option 211 will properly initialize a Hayes 2400 modem for use with RBBS. Parameter 212 is the time to wait after dropping DTR. This is used in RBBS-PC for dropping the connection after a caller logs off normally. Too short a delay will cause the modem not to re-initialize properly. The default time is 3 seconds. In order to provide the maximum flexibility (and get RBBS-PC out of the protocol writing business), RBBS-PC supports external protocol drivers via a standard interface. The external protocol driver for YMODEM, YMODEMG, IMODEM is the file YMODEM.EXE. The external protocol driver for WINDOWED XMODEM is WXMODEM.EXE. The external protocol driver for KERMIT is PCKERMIT.EXE. These protocols work only if the external drivers are available and in the drive/path specified by parameter 213. Also see parameter 107. RBBS-PC has internal code to support Xmodem, and Xmodem is also supported by external protocol drivers. Parameter 214 lets the SYSOP specify which services xmodem requests. The default is to use the internal xmodem. RBBS-PC can check right after a caller logs on whether the caller's communication program supports autodownload. Turning on parameter 215 means that RBBS will always do this check. However, this check is incompatible with come terminals and communications packages, causing them to stop displaying on the local screen. If the check is passed, RBBS-PC announces that autodownload is available and asks callers if they want to use it. This check is unnecessary for autodownload to work. The caller can control whether autodownload is used with the T)oggle command in utilities. It is recommended that this option NOT be enabled. Parameter 216 allows the SYSOP to restrict searches (either for specific strings or via the "N>ew" command by date) to a single RBBS-PC directory of files. If not restricted all RBBS-PC file directories will be searched. Parameter 217 is not implemented in CPC15-1B. Parameter 218 allows modems that require it, to have "flow control" between the modem and the PC running RBBS-PC using the "request-to-send" signal, RTS. Some modems with built-in error checking protocols require this to be set on or, should an error-free link become disconnected, the modem will never respond to the PC after RBBS-PC recycles. 12.12 Parameters for RBBS-PC NET-MAIL ------------------------------------- Parameter 221 allows the SYSOP to specify the time of day in HHMM format after which RBBS-PC is to SHELL to a batch file for system maintenance. The file that RBBS-PC will SHELL to is named RBBSTIME.BAT. It is the SYSOP's responsibility to create this .BAT file. Parameter 222 allows RBBS-PC to handle "store-and-forward" mail of messages and files. Currently the only such "net mail" that is supported is SeaDog. Page 66 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 By enabling this option, the SYSOP assumes the responsibility of configuring the "net mail" application to 1. answer the phone and determine if the caller is sending "net mail". 2. if the caller is not sending "net mail", the net mail application must invoke RBBS-PC with the following command line: RBBS-PC.EXE nodeid filename /time /baud where: "nodeid" is the node ID in the range 1-9, 0, or A-Z. "filename" is the fully qualified file name to use as the RBBS-PC ".DEF" file. "/time" is the time of day for RBBS-PC to return to the "net mail" application that called RBBS-PC. "/baud" if the baud rate that the caller dialed in at. 12.13 New users parameters -------------------------- Parameter 241 allows the SYSOP to elect to not ask new users for their default parameters. RBBS-PC typically asks new users whether their terminal supports upper case, they want line feeds, what they want for a graphics preference, what they want for a default protocol, and whether they want nulls. Sometimes these questions confuse new users, who lack the knowledge to answer them. To bypass the questions and force new users to get the defaults (upper and lower case, line feeds, no graphics, no protocol, no nulls), specify "NO" this parameter. Parameters 242 through 249 are not implemented in CPC15-1B. Parameter 250 allows new users to be always treated as new users every time that they log on. RBBS-PC normally logs new users in the users file and recognizes them as having previously logged on should they call back. If the SYSOP wants new users not to be logged to the users file, so that a new use continues to be treated as a new user every time he calls, specify "NO" to option 250. Parameter 251 allows the SYSOP to permit RBBS-PC to continue operating should the users file run out of room for new users. The user file in RBBS-PC can run out of room for new users. Until the SYSOP rebuilds the users file or expands it, there are then two options: 1. do not let the new user on, or 2. let the new user on but do not try to add him to the user file. Saying "YES" to option 251 enable new users to be allowed on on when there is no room rather than being told there is no room and then disconnected. 13.0 HAYES COMMANDS AND MODEM SWITCH SETTING CONSIDERATIONS ---------------------------------------------------------- 13.1 Hayes Modem Switch Setting Considerations --------------------------------------------- RBBS-PC is tested with a HAYES Smartmodem 1200 (i.e. external). The switch settings on the modem must be as follows: switch -- 12345678 setting - UUDDDUUD Recognizing that there are many "Hayes-compatible" (and not so compatible) Page 67 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 modems in use, this section is intended to assist those adventurous souls who use such modems and need some guidance on what the otherwise mystical Hayes switch settings mean. The following table may be of some help: Setting Function to RBBS-PC Hayes ----------------- Switch Factory RBBS-PC (NOTE "Up" means enabled or "on") ------- ------- 1 Down Up Allows RBBS-PC to control the modem using the RS-232 DTR lead (pin 20). 2 Up Up Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be English words or single digits. RBBS-PC sets this with the Hayes "V" command. 3 Down Down Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be sent to RBBS-PC. RBBS-PC sets this with the Hayes "Q" command. 4 Up Down The modem does not echo characters unless half-duplex is selected and the modem is on- line. 5 Down Down Modem is NOT to answer incoming calls. RBBS- PC monitors the ring indicator (pin 22) to determine if the phone is ringing. If it is, RBBS-PC will issue the necessary commands to the modem. 6 Down Up RBBS-PC checks for the carrier signal using the RS-232 Carrier Detect lead (pin 8). If carrier is lost, RBBS-PC hangs up the phone and re-cycles to await the next call. 7 Up Up Not really required by RBBS-PC. However in the "down" position, the telephone extension light will illuminate on a multi-line installation when the modem answers a call. 8 Down Down Enables the Smartmodem 1200 to recognize the Hayes commands issued by RBBS-PC. The most common problem, "RBBS-PC continually recycles," occurs when switch six is left in the factory position. These switch settings do not have to be changed for most other communications software packages. (You can leave the switches set as shown above if you use PC-TALK for your smart terminal communications. However, you will be advised to give the modem an "ATZ" command before using PC-TALK in order to reset the registers correctly.) RBBS-PC should be used only with versions 123 and above of the Hayes Smartmodem 1200 and with version 247 and above of the Hayes Smartmodem 2400. Earlier versions do not answer the telephone properly. The ATI command will cause the Smartmodem to tell you its version. Hayes is now shipping an external modem called the Hayes 1200FE that has 10 switch settings. To run RBBS-PC switches 9 and 10 of the 1200FE must be left up (the factory setting). Hayes is also now shipping an internal modem called the Hayes 1200BFE that has 6 switch settings. To run RBBS-PC Page 68 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 switches 4, 5, and 6 must be left up (the factory setting). If you can't figure out what the switching settings on these new modems should be based on the switch settings given for the "original" Hayes 1200, CALL HAYES TECHNICAL SUPPORT! Since I don't have the newer modems, I won't be of much help if you call me. 13.2 Hayes Command's Considerations ---------------------------------- The Hayes commands used to control the modem are all external to RBBS-PC beginning with version CPC13-1A. These command strings are in the RBBS- PC.DEF file which may be modified by any file editor that can handle ASCII files (i.e. DOS' EDLIN utility). The RBBS-PC.DEF file contains five Hayes command strings -- one on the second line of the .DEF file and four on the last line of the .DEF file. Using RBBS-PC's CONFIG utility's defaults, the command strings are as follows. 13.2.1 Command to Initialize the Modem ------------------------------------- The second command string in the .DEF file is the first Hayes command string on the last line of the .DEF file and is: Command Meaning AT Signifies the following characters are Hayes commands. Z Causes a software reset and applies all default values. This command is ALWAYS issued and is the first command issued to the modem every time RBBS-PC gets ready for calls. 13.2.2 Command to Set Up the Modem --------------------------------- The first command string, on the second line of the .DEF file, is ALWAYS issued and is the second command issued to the modem every time RBBS-PC gets ready for calls. If the appropriate CONFIG has been set to tell RBBS-PC to answer on a ring greater than zero, the command string is: Command Meaning AT Signifies the following characters are Hayes commands. M0 Turn the monitor speaker on the modem off permanently. Q1 Do not return result codes to the PC. S2=255 Disable escape code detection. S10=30 Do not drop disconnect user unless carrier drops for more than seconds (you may want to set this to 15) E0 Do not echo characters back to the PC when receiving Hayes commands. S0=x "x" is set as follows: S0=254 to answer on a specific number of rings > 0 S0=255 to enable "ring-back" If RBBS-PC has been set to answer on zero rings, Q and S0 are different and V1 and X1 are added to this command string and it is: Command Meaning AT Signifies the following characters are Hayes commands. M0 Turn the monitor speaker on the modem off permanently. Q0 Send result codes to the PC. S2=255 Disable escape code detection. S10=30 Do not drop disconnect user unless carrier drops for more Page 69 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 than seconds. Some of the Hayes ROM's have a bug in them that causes the modem to only answer at 1200 baud if anything other than the factory default is used for S10. If you have such a problem, simply set S10 equal to 7. E0 Do not echo characters back to the PC when receiving Hayes commands. S0=1 Answer the phone on the first ring. V1 "Extended" result codes are to be transmitted as words. X1 Tells the modem to send "extended" result codes to the PC. 13.2.3 Command to Determine What Ring to Answer On ------------------------------------------------- The third command string in the .DEF file is the second Hayes command string on the last line of the .DEF file and is: Command Meaning AT Signifies the following characters are Hayes commands. S1? Requests the modem to return the number of times that the phone has rung. This command string is only issued when CONFIG has been used to tell RBBS-PC to answer on a specific number of rings other than 0. Some modems have trouble with the S1? command because they do not recognize the ? part of the command. Again, verify what your modem is capable of handling. 13.2.4 Command to Answer the Phone --------------------------------- The fourth command string in the .DEF file is the third Hayes command string on the last line of the .DEF file and is: Command Meaning AT Signifies the following characters are Hayes commands. Q0 Tells the modem to send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. V1 "Extended" result codes are to be transmitted as words. A Tells the modem to answer the phone immediately. This is only issued if the number of rings to answer on are greater than 0. RBBS-PC utilizes the extended verbal results code (CONNECT, CONNECT 300, CONNECT 1200, and CONNECT 2400) to determine the callers baud rate. Some Hayes 300 modems don't function with RBBS-PC because they do not recognize the "X1" command. If you have a modem like this, simply remove the X1 command from the command strings in the .DEF file. 13.2.5 Command to Take the Phone Off the Hook -------------------------------------------- The fifth command string in the .DEF file is the fourth Hayes command string on the last line of the .DEF file and is: Command Meaning AT Signifies the following characters are Hayes commands. Q1 Do not return result codes to the PC. E1 Echo characters back to the PC when handling Hayes commands. H1 Take the modem off the hook (i.e. busy out the line). M0 Turn the monitor speaker on the modem off permanently. This command is ALWAYS issued whenever the SYSOP is doing local maintenance Page 70 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 (i.e. hits ESC) or a user hangs up. 13.2.6 Commands to Initialize the Modem Firmware ------------------------------------------------ The commands to initialize the modem firmware are not contained in the .DEF file, but rather are dynamically set (or reset) each time that CONFIG is invoked. There are essentially three commands: 1. A command to clear the modem's firmware. 2. A command to initialize the modem's firmware. 3. The command to write the initialized firmware to the modem's non-volatile memory is "&W". The default command to clear the modem's firmware is: Command Meaning AT Signifies the following characters are Hayes commands. &F Load the modem active configuration area with the factory profile contained in the Hayes ROM. The default command to initialize the modem's firmware is: Command Meaning AT Signifies the following characters are Hayes commands. &C1 Data carrier detect tracks the state of the data carrier from the remote modem. &D3 Modem is to assume the initialization state if it detects ON- to-OFF transition of DTR. The newer versions of the Hayes 2400 baud modem (ROM 249 or greater) and some clones do not allow RBBS-PC to recycle properly when the &D switch is set to 3. If you are having a problem, set the it to &D2. B1 Set the modem to Bell 212A mode when the 1200 BPS data transfer rate is selected. E0 Do not echo characters of the modem commands issued by RBBS-PC back to the PC running RBBS-PC. V1 Select long-form result codes. M0 Disable the modem's speaker when carrier is detected. S0=0 Disable "auto-answer" mode. &T5 Disallow a request from the remote modem for a remote digital loopback test. These three commands are ALWAYS issued in CONFIG when option 211 is selected. These commands can be temporarily altered by changing them via option 205 of CONFIG prior to issuing option 211. 14.0 RBBS-PC's FILE MANAGEMENT SYSTEM -------------------------------------- The File Management System (FMS) is a facility built into RBBS-PC for managing the files subsystem. SYSOPs must make files available for downloading, and callers must be able to find out what files can be downloaded and upload new files for sharing with others. Callers can search for files available for downloading by a substring in the file name or description (command S), on or after a specified date (command N), or by a subject matter (commands L,N,S). The files system is organized into four logical areas: 1. Upload drive/subdirectory (Uploaded files written to here) 2. Upload directory (Descriptions of uploaded files written to here) 3. Drive/subdirectory of searchable directories (subject directories, shared FMS directory resides here) Page 71 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 4. Download drives/subdirectories (downloadable files stored here) An RBBS-PC "directory" of files is NOT A DOS DIRECTORY. It is just a text file containing information about the files uploaded or available for downloading. A SYSOP must specify via CONFIG where the files are stored that are available for downloading. This can be specified either by a list of download drives (e.g. "CDE") or a list of subdirectories (e.g. C:\DOWN1\, C:\DOWN2\). ONLY THE FILES STORED IN THE DOWNLOAD DRIVES/SUBDIRECTORIES ARE DOWNLOADABLE (with one exception: SYSOP's can download from the upload drive). CONFIG is also used to specify where uploaded files are written to, either as a drive letter (e.g. "D") or as a subdirectory (e.g. D:\UPLDS\). The SYSOP has the option to make the upload drive/subdirectory also a download drive/subdirectory. Only by making the upload drive/subdirectory also be a download can files uploaded be immediately available for downloading by others. Most prudent SYSOPs do not make files that have been uploaded available until after they have had a chance to review them. A description of an uploaded file is automatically appended by RBBS-PC to a special RBBS-PC directory of files called the upload directory. RBBS-PC appends entries describing the new uploads to the end of the upload directory in the format <file name> <file date> <file size> <file description> <category code> <file name> is the name of the uploaded file, and has the format X.Y, where X is the file name prefix and Y is the file name extension. <file date> is the date the file was uploaded in the format MM-DD-YY. MM is the number of month (1 digit months include a leading zero, so that March is 03). DD is the number of the day (1 digit days have a leading 0). YY is the last two digits of the year. March 7, 1987 would be expressed as "03-07-87". <file size> is the size of the file in bytes. <file description> is a description of the file whose maximum length is between 40-46 characters, depending of what CONFIG parameter 198 was specified as. <category code> is an optional 3 character code for the category the file belongs to. This code is included only if there is a shared FMS directory and it is the same physical file as the upload directory. SYSOPS can make it easier for callers to find what files are available by classifying the files into categories. RBBS-PC supports two fundamentally different ways of categorizing files: 1. A single shared master directory file XXX.YYY where YYY is the directory extension and XXX is the name of the FMS directory. A file entry in the master FMS directory is classified as being in a category by putting a three character category code at the end of the entry. For example, "GAM" might be the code for all Page 72 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 games. 2. Physically separate multiple directory files XXX.YYY where YYY is the directory extension specified in CONFIG parameter 189 and XXX is the name of the directory. Callers know the directories by name. RBBS-PC knows the directories by where they are located and the fact that the file has the directory extension. There can be as many directory files as desired. A file is classified as in a category simply by physically listing it in the directory. For example, the directory GAMES.DIR contains a list of all games. The physically distinct directories should be text files satisfying the following constraints: o The file directories must have an extension of up to three characters. The default extension is ".DIR". The 8-character file name and extension can be anything you want as long as it is a valid DOS file name. o Filename should start in column 1. o Program size can be between columns 14 & 22. o Date available for downloading must start in column 24 and should use MM-DD-YY or MM/DD/YY format. o Description should start in column 34. Callers learn what files are available by listing RBBS-PC directories. With the exception of the upload directory, all RBBS directories must be in a single drive/path specified by parameter 200 of CONFIG. This is where RBBS-PC searches when a caller asks to list files by date, substring, or category. The upload directory will be viewable also if it is placed in this drive/subdirectory. If placed elsewhere, whether the upload directory is viewable will be determined by the security level of the caller. The SYSOP specifies a minimum security to view the new uploads via CONFIG parameter 199. If the SYSOP has chosen to use the RBBS-PC File Management System (FMS), the SYSOP must specify what categories are included in the master FMS directory. This is done in a directory category file whose name is specified in CONFIG parameter 196. The format of entries is as follows: "<category name>","<category codes>","<category description>" There are three entries to a line, each enclosed in quotes and separated by a comma. The first entry is the name of the category. This is how the categories should be listed in the menu for the L)ist command and what the caller must specify when asking for lists by category. Most SYSOPs either number the categories (1,2,3,etc.) or give them names that describe their contents, are easy to remember, and short enough to type quickly (e.g. GAMES, UTILS, BASIC). The category codes are a list of all codes included in this category and has the format "X1,X2,...,XN" where X1,X2,..,XN are the individual codes. Each individual code must be separated from the others by a comma and there must not be any spaces inside the category codes. A category can be a composite consisting of several categories. For example, if "PRU" is printer utilities, "SCU" is screen utilities, and "FU" is file utilities, Page 73 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 then the codes for the category "UTILS", consisting of all utilities, would be "PRU,SCU,FU". The category description is what RBBS-PC will print to the caller at the beginning of a search in a directory. For example, the command to search directory GAMES for all entries with the string BAS will be prefaced by Searching directory GAMES for BAS - Games and Graphics if "Games and Graphics" is the description with directory GAMES. 14.1 Using a Single Master Directory ------------------------------------- One possible extreme in setting up RBBS-PC is to have a single master directory and no other. This implies that the FMS directory is the same as the upload directory. Files uploaded will have descriptions appended to the FMS directory which will therefore ALWAYS BE CURRENT. This does not mean that the new uploads will be listable. The caller has the option to specify that the upload is private to the SYSOP, in which case a special category code will be written (***) that requires SYSOP status to view. Also, if the category code is the default category code specified in the configuration, only callers whose security level is higher than the minimum to view new uploads can view them. A SYSOP can prevent callers from seeing new uploads by not allowing uploads to classify the uploads and by setting the minimum security to view be high or making the default category code be "***". The advantages of a using the FMS master directory are: o Callers will get the latest files listed first. The files in the FMS directory must be listed from oldest to newest. This file is read by RBBS-PC in reverse order from the bottom up so that the latest files get listed first. o Callers can download download as soon as they see what they want. Listings from the FMS directory terminate with the option to simply list the files wanted to download. The caller does not have to terminate the listing first nor type "D" for download. Callers can grab the files as soon as they see them on their screen. o Listings resume where left off after downloading. Callers need not terminate a list just to begin downloading. After downloading in the midst of listing files, the listing will resume right where it was before downloading. The caller does not have to write down all the files they want, then get out of the listing and start downloading. o Date searches are very fast. As soon as a file is hit that has a date earlier than desired, the date search terminates rather than needlessly continue to examine yet older files. Also, the date search algorithm for FMS directory entries is 25% faster than the date search in other directories. Page 74 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 o Classifying files is fast and easy. Simply load up the directory into any favorite full screen editor, overtype the correct category code, and that's it: one quick and simple change does it. Remember too, that uploaders can be given the option to classify uploads, in which case the SYSOPs work is limited to reviewing the suggestion of the uploader and correcting mistakes. o Complex classifications are easy to implement and change. Classifying a category into its basic category immediately and without additional work causes it to be included in all other composite categories that include it. Hence it is simple and easy to build complex, interrelated categories. The category scheme can be changed at will simply by changing the directory category file. And if the basic categories need to be changed, such as a rename or splitting a basic category into two new ones, this is as easy as a global search and replace in an editor. Because creating useful categories does not cause SYSOPs a lot of work, they can afford to put up more complex classifications that help callers find the files they really want. 14.2 Reasons It May Not be Possible to Use a Single FMS Directory ------------------------------------------------------------------ While the shared FMS directory has many significant advantages, it is obviously absolutely unusable in networks (such as CORVUS' Omninet) that do not allowed files that change in length to be shared. Additionally the shared FMS directory has other limitations that may force SYSOPS to elect not to use it at all or to use it with additional directories. Physically separate directory files that correspond to a single directory subject are read and displayed sequentially from the top to the bottom in RBBS-PC. The only restriction placed on such a file is that the file entries must have the month, day, and year somewhere in the first 31 columns in order for the N)ew command to work properly. The shared FMS directory is much fussier and will not work properly unless the following limitations are observed: 1. Files must be stored in date order from oldest to newest. Common practices this precludes are to store the files in alphabetical order by name, or to group the files by sub-categories. For example, each communication program has all its files together. 2. The only text in the file must be a file directory entry. Multiple line header text, or file descriptions can not be handled by the File Management System. One line file entries are all that is supported. 3. Only a single entry can be included for each file. A common practice that will no longer work is to have a multi-line description of a file by leaving the name/date/size blank and continuing the description on the following line. 4 The file date must have a leading 0 for 1 digit parts and must have the month, day, and year in only a specific column in order for the N)ew command to work properly. Page 75 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 A shared FMS directory is perfectly compatible with additional directories. RBBS-PC simply looks first in its list of categories in FMS. If a request for a directory is not found there, it will then look on the directory drive/path for the directory, if directory searches are not limited to the FMS via CONFIG parameter 192. For example, the SYSOP can include a directory called NAME which is a master list of files sorted by file name, as well as directories maintained in the FMS directory. 15.0 SETTING UP ".BAT" FILES FOR RBBS-PC ----------------------------------------- Many SYSOPS have set up batch files to invoke RBBS-PC automatically and to re-invoke RBBS-PC should there be a power outage. These files range from the simple to the sublime in terms of complexity. In a multiple RBBS-PC environment, these .BAT files CANNOT BE SHARED. If you are going to exit RBBS-PC and transfer control to DOS remotely (either via the SYSOP's function 7 or via "doors"), it is necessary that: 1. RBBS-PC be executed from a batch file. 2. The batch file which is executing RBBS-PC contain an "IF" statement that checks for the existence of the batch file which RBBS-PC dynamically builds when either "doors" or SYSOP function 7 is invoked. 3. Within the "IF" statement, the logic exists such that the batch file dynamically built by RBBS-PC for the "doors" functions or SYSOP function 7 will be invoked if it exists. As a very simple example, let us assume that: 1. the batch file that invokes RBBS-PC is named A:RBBS.BAT, and that is what was entered for option 84 of CONFIG.BAS, 2. the name of the batch file that RBBS-PC will build dynamically for either "doors" or SYSOP function 7 is A:RCTTY.BAT, and that is what was entered for option 83 and 3. the compiled version of RBBS-PC is being executed and is named RBBS-PC.EXE and is on the default disk drive. 4. you have elected to use the watchdog utility program. 5. COM1 was designated as the communication port to be used by RBBS-PC. 6. the CALLERS file is on drive A. Then A:RBBS.BAT (in a non-MultiLink environment) would contain the following: WATCHDG1 OFF IF EXIST A:RBBSxF1.DEF DEL A:RBBSxF1.DEF IF EXIST A:RCTTY.BAT DEL A:RCTTY.BAT RBBS-PC x filename (see note of values available for "x" and "filename") IF EXIST A:RBBSxF1.DEF GOTO EXIT IF EXIST A:RCTTY.BAT WATCHDG1 ON IF EXIST A:RCTTY.BAT A:RCTTY.BAT A:RBBS.BAT :EXIT NOTE: When running RBBS-PC.EXE, RBBS-PC will check for the "x" in the command line that invoked RBBS-PC. The "x" on the execute line is extremely important to the correct operation of RBBS-PC. If you are running in a local area network environment then the "x" should be a number between "1" and "0" or a letter between "A" and "Z". If "x" is omitted from the command line, RBBS-PC will look for a file named RBBS- PC.DEF. RBBS-PC uses the parameter in the command line to Page 76 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 determine the correct RBBSxPC.DEF file to use for its configuration parameters if the second parameter is not present. If the second parameter is present, then RBBS-PC assumes this is the fully qualified file name for the .DEF file that this node should use. 16.0 THE USE OF RBBS-PC "DOORS" ------------------------------- The RBBS-PC "door" concept is that of allowing a SYSOP to set up a "door" through which users can exit from RBBS-PC and enter other applications. In previous versions of RBBS-PC (i.e. prior to CPC12-3A) this had been called "windows" but because of the confusion this created with the WINDOWing concepts of other software, it has been re-labeled "doors". RBBS-PC's "doors" are nothing more than .BAT files that the SYSOP has created to allow users to exit from RBBS-PC and enter other applications (i.e. databases, etc.). The SYSOP is responsible for writing the .BAT files that users will be allowed to invoke. Assuming that RBBS- PC is brought up by DOS via an AUTOEXEC file that invokes RBBS.BAT, a door called EDIT exists that consists of a .BAT file (EDIT.BAT) which contains the commands CTTY, EDLIN, and RBBS.BAT. In order to exit RBBS-PC (either for a "door" or for the remote SYSOP's function 7) without the code that the BASIC compiler generates for you dropping the remote user, it is necessary for the compiler that RBBS-PC is compiled under be "patched" as described in Appendix O otherwise the user will be disconnected upon returning to RBBS-PC. Here is pictorially what happens: DOS | \|/ AUTOEXEC.BAT | \|/ RBBS.BAT +--------->RBBS-PC.EXE | \|/ "RUN" | / | +-------------ends | \ RBBS.BAT | \|/ RCTTY.BAT<-----invokes door called "EDIT" | \|/ EDIT.BAT +--------->EDLIN.COM | | EDIT.BAT <--------ends | \|/ RBBS.BAT \|/ +--------->RBBS-PC.EXE | | welcome back from door and RBBS-PC continues Page 77 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 A sample .BAT file for a program called TEST.EXE would look like this: CTTY COM1 TEST.EXE CTTY CON RBBS-PC.BAT and assumes: 1. That you are going to be using COM1. 2. That the program "TEST.EXE" is on the default drive. 3. That the batch file to invoke RBBS-PC is called "RBBS-PC.BAT." 4. The the batch file "RBBS-PC.BAT" is on the default drive. CTTY METHOD -- The first command, "CTTY COM1", assigns most standard input and output to the communications port number 1. The second command, "TEST.EXE", invokes some test program that you write that reads from and writes to the standard input and output devices (i.e. the keyboard and the screen). The third command, "CTTY CON", reassigns the standard input and output back to the local PC's keyboard and screen whenever TEST.EXE ends. The fourth command simply invokes another batch file named RBBS.BAT (which presumably invokes RBBS-PC). REDIRECT I/O METHOD -- The first command, "COMMAND /C TEST.EXE <COM1 >COM1", starts a secondary command processor, loads TEST.EXE and assigns most standard input and output to the communications port number 1. "Most" is the key word here since PC-DOS does not have a way of redirecting "STANDARD ERROR" like it does for "STANDARD IN and STANDARD OUT". To solve this problem STDERR.COM is included as part of the basic RBBS-PC system. This program was provided by Quarterdeck Systems. Run "STDERR.COM" one time only before you start RBBS-PC. I suggest that you include it in your AUTOEXEC.BAT file. This program works with all versions of PC-DOS 2.0 through 3.2. To first set up and test a door, DO NOT USE RBBS-PC. Rather set up with 1. your modem on autoanswer (i.e. it answers the phone) 2. a .BAT file that redirects all input and output to the communications port that you are going to use using the IBM DOS CTTY command. 3. make sure the .BAT file invokes the program that you want to use as a "door." 4. invoke the .BAT file that you set up in steps 2 and 3. 5. dial up the modem that you set in autoanswer mode in step 1. 6. get your "door" to work in this environment. If you have problems with steps 1 through 6, call your friendly IBM support or the vendor of the software that you want to use as a door and ask them to teach you about either their software or the CTTY command and their software's compatibility with the CTTY command. AFTER YOU HAVE YOUR DOOR WORKING, to set up a "door" for RBBS-PC, you must 1. list the name of the door (i.e. the .BAT file which you already got working and debugged and are responsible for setting up) in MENU5. 2. indicated that doors are available (via CONFIG.BAS' option 81). When a user invokes the D>oor command, RBBS-PC will: 1. List MENU5, 2. Check that the door that the user selects was specified in MENU5, 3. Check that the .BAT file exists (on the default drive), Page 78 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 4. Dynamically create a .BAT file with the name specified by the SYSOP in option 83 of CONFIG.BAS that: a. invokes the .BAT file of the window specified,and b. re-invokes RBBS-PC after the user EXITS from the "door" by invoking the .BAT file that the SYSOP specified in option 84 of CONFIG.BAS. The purpose of "doors" is to allow for the "horizontal" growth of RBBS- PC. Clearly RBBS-PC has about all that IBM's BASIC compiler can handle. In order to not limit the application of RBBS-PC either to BASIC or the current compiler, "doors" was chosen as a mechanism to allow SYSOP's to make available other features (i.e. databases, games, etc.). Hopefully with RBBS-PC as a base, the limitations on doors will only be the SYSOP's resourcefulness AND IBM'S DISK OPERATING SYSTEM (see chapter 18)! The design of the .BAT file that is to be used as a "door" is critical and is the responsibility of the SYSOP. At the very minimum it should handle the communication port I/O. This can be done in a very primitive way using the DOS CTTY command and and a utility similar to WATCHDOG (written by Jim Reinders) that is described in chapter 19. When the file RCTTY.BAT is executed, it executes another batch file with the name of that particular door. DOS does not return to the RCTTY.BAT. So, at the end of your doors batch file, you must reinvoke RBBS.BAT. The way that the doors menu works is it checks to see if the door name that you wanted to open is in MENU5. If it is in all capital letters in the RBBS file MENU5, it runs the batch file of that name with the extension ".BAT". In general, the program invoked as a "door" has to do is print everything to the Comm port and if you wish, echo it to the screen. The initial part of any "door" should read in the parameters passed to the "door" in the "node" record (see line numbers 43070 and 44000 of RBBS-PC.BAS) and establish the communications parameter appropriately. Finally, if the preceding discussion of "doors" is a complete mystery to you, contact a SYSOP of an RBBS-PC that is using "doors" and ask for help. CHESSDOR is one of the more professional "doors" that has been shared with me. It was written by Bob Westcott and his data number is (603) 424-5497. While I don't suppose it needs to be mentioned, if you call Bob and take up their time learning about "doors" for personal gain (i.e. you are a consultant or some company's employee being paid to write a "door") have the courtesy to tell them. The "user helping user" concept does NOT imply that anyone should be taken advantage. Bob (or anyone else who has acquired specialized knowledge) has the right to be remunerated for their efforts if their knowledge is being used to further commercial purposes and they request it. The "door" concept stretches IBM's DOS' capabilities and requires an extraordinary knowledge of how both DOS, the DOS CTTY command, and .BAT files work. 17.0 THE SECURITY FEATURES OF RBBS-PC -------------------------------------- RBBS has always been an open system designed for public use. A SYSOP should always ASSUME that EVERY FILE ON THE PC running RBBS-PC CAN BE DOWNLOADED AND/OR DESTROYED. However, RBBS-PC has extensive safeguards that systematically enhance security and privacy. For example, RBBS-PC has the Page 79 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 logic within it's code to prohibit anyone (including SYSOP's) from downloading the RBBS-PC "system" files described in section 6.1. RBBS can still be run as a wide-open system, but the SYSOP has many additional options to restrain access. These security options make RBBS much more suitable for private and business use. RBBS-PC's security is controlled by three things: 1. the system configuration file (RBBS-PC.DEF), 2. the two external security files for a. passwords (PASSWRDS), and b. file downloads (FILESEC), and 3. the users file (USERS) in which each user has an assigned security level. The users file is controlled by the SYSOP's user maintenance function 5 as described in chapter 18. To change a specific users security level you select the M>odify option and then the S>ecurity option. This allows you to set the security level for a user. Users cannot set their own security levels. Section 17.3 describes how to implement special passwords that provide special privileges to the groups that issue them. Section 17.4 describes how specific files, groups of files, or even whole disk volumes can have download security levels associated with them. 17.1 RBBS-PC's Security Features -------------------------------- Each user has an assigned security level. This is an integer in the range -32,000 to +32,000. There are then over 65,000 possible security levels. Each command in RBBS-PC also has a security level assigned to it. Security assignments are controlled by the SYSOP. To use a command, the caller's security level must be at least as high as the command's security level. The SYSOP can assign a file or group of files both a security level and a password. To download a file, a caller must have a security level at least as high as the file's and be able to give the file's password (if one is present). All users must pass these security tests, including anyone with SYSOP privileges. Messages can now be assigned a password by their creator. Then only persons who are able to give that password can read or kill the message. Messages with password protection will show <PROTECTED> when scanned. Callers have no way of distinguishing messages to private individuals and to groups except by how they are addressed. Persons with SYSOP privileges can read all messages. Section 17.2's description of sending a message to an AUTHORS SIG as an addressee with the password of AUTHORONLY shows how to send a message to a special group. Security violations are logged to the CALLERS file. These include attempting to use functions without sufficient security clearance, and failure to give required passwords. RBBS-PC's default configuration is that of an "open" system. RBBS-PC's security system provides the SYSOP with several choices on how to run RBBS-PC. The chief ones are as follows: 1. Change the bulletin board from an open system available to all callers, to a pre-registered system available only to specified users. To support this option, there is a function in the SYSOP's user maintenance option 5 to ADD users. Page 80 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 2. A SYSOP can set up different "classes" of users by assigning different security levels to different users. Concurrently the SYSOP would have to assign different security levels to different commands. For example new callers might be permitted only to leave a comment, read bulletins, and list files that can be downloaded. Or there might be a group of files assigned a security level that only members of a special interest group can download. 3. The SYSOP can segregate the functions of the bulletin board into different groups based on a password. A specific file or group of files can be downloadable only to those who knew the password. Similarly, messages can be made open to everyone knowing the password but closed to everyone else. This way there can be semi-private portions of the bulletin board. 17.2 Examples of Uses for RBBS-PC's Security System --------------------------------------------------- Some examples of how a SYSOP can tailor RBBS-PC using RBBS-PC's extensive security features follow. SPECIAL INTEREST GROUPS -- A special interest group (SIG) in a users group wishes to run a RBBS for both the general public and its own use. An example would be an authors SIG for persons interested in publishing books and articles or developing commercial software. A definite need would exist to be able to address messages to everyone in the SIG without making them open to every caller. The SIG would establish the convention to password protect general SIG messages with the password AUTHORONLY, and to address them to AUTHORS SIG. Another example would be a bulletin board devoted to the exchange of software. Allowing persons to use the message subsystem would only interfere with the primary purpose of the bulletin board. Therefore the SYSOP removes from the menu the functions for leaving and reading messages. To prevent a person from using the functions to leave or read a message (even though they are not displayed), the SYSOP assigns these functions a security level higher than a person who logs on normally would be assigned. Another example of using RBBS-PC's security system would be to set up an agreed upon temporary password such that when a user logs onto the system they can issue the password and get longer than normally allowed. If the time for normal users is 30 minutes, the SYSOP can set up the special password SOFTEXCHANGE, with a maximum time on of 150 minutes instead of the normal 30. By shifting over to this special password after logging in, members can get extra time if they need it. SOFTWARE SUPPORT -- An author of a freeware program offers RBBS support to all persons who register their copies and send a contribution of, say, $35 per copy. The registered user can get answers for problems and download free updates and sample applications. The author wants anyone to be able to call just to find out about the service. New callers get a security level of 2 automatically assigned to them. This allows them to use only the message subsystem. The file subsystem is assigned a security level of 7. Contributors are added by the SYSOP with a security level of 7 and a pre-assigned password. Except for SYSOP functions, registered users have free reign in the RBBS. CLIENT SUPPORT -- A SYSOP on a public RBBS also works as a management consultant. She has several associates who work with her on projects. She needs to be able to send and receive messages from her associates which the general public should not see. So they agree on a message password Page 81 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 NOTPUBLIC. To support her different clients she also needs to leave private files for downloading. To each client she assigns a special downloading password. To restrict downloading to just that client, file names are put in the file security file with the appropriate password. Only persons with the password can then download them. PRIVILEGED ELECTRONIC MAIL -- A company uses RBBS-PC to help support its regional offices. Only regional vice-presidents should be able to download certain management reports. In file security these reports are assigned a high security level of 9, which only managers get. 17.3 How to Implement the Password File --------------------------------------- CONFIG allows the SYSOP to designate the name of the file containing the privileged group passwords to RBBS-PC. Since this file is a normal ASCII file, the SYSOP can use any text editor to create and update the file it. Put the information for each password on a single line and separate the fields with commas. It is important to note that EACH record of both the password or the file security file must contain FOUR fields (i.e. THREE commas). For the password file, the format is: <password>,<security level>,<max time on>,<subscription period> Note: Max time is in units of minutes, subscription period is in number of days. Two examples are: EXTEND,5,120,9999 ,7,128, If you are using COPY CON to create this file you "MUST" press F6 followed by a Ctrl/Z at the end of the last entry prior to pressing carriage return. A user who issued the password change function and supplied the password EXTEND would have their security level temporarily set to 5 and be granted an elapsed time of 120 minutes for the current session (the users elapsed time per day would still be whatever was set in option 15 of CONFIG), and a subscription period of 9,999 days. A user who logged on with a security level of 7 would automatically be granted 128 minutes on the system, and the subscription period would be unchanged from whatever it was before. 17.4 How to Implement the Security for Download Files ------------------------------------------------------ CONFIG allows the SYSOP to designate the name of the file containing the passwords and security levels that can be used to restrict downloads of specific files, volumes, or files names meeting certain "wildcard" criteria. This file contains file names with download restrictions in the format: <filename>, <security level>,<password> Note: Each line is a record and ends with carriage-return line-feed. The only optional field is the password field for a filename. By leaving the password field empty, no password is assigned to a file. The commas between the fields are necessary. YOU MUST HAVE TWO COMMAS ON EACH LINE even if you do not have a password associated with the file. Page 82 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Some examples would be: COMMAND.COM, 10,DOS PAYROLL.DAT, 99,BANKRUPT CALLGIRL.SEX,,ILLEGAL \FINANCE\STOCKS,100, The file COMMAND.COM could not be downloaded unless a user had a security level equal to or greater than 10 AND could supply the password "DOS". The file PAYROLL.DAT could not be downloaded unless a user had a security level equal to or greater than 99 AND could supply the password "BANKRUPT". Any user could download the file CALLGIRL.SEX if they could supply the password "ILLEGAL". Any user with a security level of 100 or higher could download the file STOCKS in the DOS subdirectory FINANCE without supplying any password. Additionally "wild-card" characters and drive designators can be used to protect or restrict certain classes of files (by extension, by drive, etc.) from being downloaded. Some examples would be: A:*.*,8, E:*.SEC,2,PW1 A*.M*,0,GX3 XY?X.*,9,3XG All files on drive A would require the users to have a security level of 8 in order for a user to download them. Any user who wanted to download a file whose extension was ".SEC" and was found to be on drive E would have to not only have a security level of at least 2 but to also give the password PW1. The third entry above would require a user who wanted to download any file on any drive with a prefix that began with "A" and an extension that began with "M" to have a security level of at least 0 and to enter the password GX3. Finally, the last entry above would require any user who wanted to download any file on any drive whose four-letter name began with "XY" and whose last letter was "X" with any extension to have a security level of at least 9 and enter the password 3XG. The wildcards "*" and "?" operate just like they do in DOS with one exception. The "?" requires a character. In DOS the name "HAPPY" satisfies the file spec "HAPPY?" but it does not in RBBS. To get exceptions to the general rule, just put the exceptions first. RBBS-PC's file security search stops with the first applicable entry that it encounters. For example, 1. if you want all files on the B drive to require the user to have a security level of at least 3, 2. except that files on the B drive with the extension ".SEC" would require the user to have a security level of at least 6, and, 3. regardless of the disk drive that they were on, any file beginning with "MES" with an extension of ".SEC" would require the user to have a security level of at least 12 you would enter the following into the file security file MES*.SEC,12, B:*.SEC,6, B:*.*,3 Page 83 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Special Note: RBBS is hard coded so that there are some files that nobody can download -- not even the SYSOP. These are RBBS-PC.DEF, users, messages, callers, group password, comments, the file security, and backup files. Similarly the batch files that control RBBS and let the caller exit to DOS 2 can not be downloaded. The default security file provided with RBBS-PC is empty. 17.5 How to Implement the Security for RBBS-PC Commands -------------------------------------------------------- RBBS-PC allows each command to be assigned it's own security level. A user who wishes to invoke an RBBS-PC command must have at least the same security level as the command. Let's assume that a SYSOP wants to set up the following classes of users: Classification of Users Security Level "Locked Out" Users 0 New Users (first time) 1 Normal Users 2 Users who can "view" a Conference 3 Users who can enter Messages 4 Users who can download files 5 Users who can upload files 6 Users who can Join a Conference 7 Users who can do some SYSOP commands (Jr. SYSOP's) 8 Users who can enter a "door" 9 Users who can enter all SYSOP commands (Co-SYSOP's) 10 The following table illustrates one method of assigning each RBBS-PC command it's own security level: Security Level Subsystem/Command Assigned to Command Messages Subsystem A>nswer questionnaire............... 4 B>ulletins.......................... 1 C>omments........................... 1 D>oor subsystem..................... 9 E>enter message..................... 4 F>iles system....................... 1 G>oodbye............................ 0 I>nitial welcome.................... 1 J>oin a conference.................. 7 K>ill messages...................... 4 O>perator page...................... 1 P>ersonal mail...................... 2 R>ead messages...................... 2 S>can messages...................... 1 T>opic of messages.................. 1 U>tilities (more)................... 1 V>iew a conference.................. 3 W>ho's on other nodes................3 Files Subsystem D>ownload........................... 5 G>oodbye............................ 0 L>ist file directories.............. 4 N>ew files.......................... 5 S>earch directories for string ..... 1 U>pload a file...................... 1 V>erbose listing of ARC file........ 1 X>Expert mode on/off................ 1 Page 84 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Utilities Subsystem B>aud rate.......................... 1 C>lock (time of day)................ 1 F>ile transfer protocol............. 1 G>raphics........................... 1 L>ength of page..................... 1 M>essage Margin..................... 1 R>eview preferences................. 0 S>tatistics of system............... 1 T>oggle (line feeds, etc.).......... 1 U>serlog............................ 2 GLOBAL commands ?>What can be done.................. 1 H>elp with a command................ 1 Q>uit to another subystem or exit... 1 X>Expert/novice toggle.............. 1 SYSOP Subsystem 1>List comments..................... 8 2>List callers log..................10 3>Recover a Message................. 8 4>Erase comments.................... 9 5>USERS maintenance.................10 6>Toggle page bell.................. 8 7>Exit to DOS 2.x or above.......... 9 17.6 Beware of the "Trojan Horse!" ----------------------------------- Despite RBBS-PC's security always remember that you should always assume: "EVERY FILE ON THE PC RUNNING RBBS-PC CAN BE DOWNLOADED, MODIFIED, AND/OR DESTROYED!" RBBS-PC's security system appears to be so fool-proof that some individuals have resorted to uploading programs that appear to do one thing, but actually do something else. These "trojan horse" programs search all the disks that are connected to the PC that the program is running on for such RBBS files as RBBS-PC.DEF or USERS. The program then copies these files to an innocuously named file that can be downloaded later when the person who uploaded it logs onto the system again. Since RBBS-PC.DEF contains the pseudonym that the SYSOP can use to logon on remotely as the SYSOP, once the user downloads a copy of it the user can then log on as the SYSOP and do just about anything including exiting to DOS and formatting all the disks on the system. Similarly, the USERS file contains passwords and the security levels of everyone on your RBBS -- some of whom may have SYSOP privileges. You can protect yourself against anyone logging on as you, the SYSOP, by not allowing anyone to logon as the SYSOP remotely. To do this read chapter 11 regarding parameters 3 and 4. You can protect yourself against unauthorized access of the USERS file by simply not allowing any user to have SYSOP privileges. Of course there is the "trojan horse" program that doesn't even bother with the above, but simply destroys all the disk files on all the disks that are connected to the PC that is running the program. See the rest of chapter 17 to see how you can protect yourself against such programs. Page 85 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 18.0 SYSOP FUNCTIONS ------------------- The SYSOP functions are not available to the general user, and it should be noted that the SYSOP should not use some of the user functions either because the code will not work correctly if called from the main console, or the function is not for use by the SYSOP. Such functions are the <O>perator, <N>ewbaud, <PW> password, and file upload/download using XMODEM. File download using ASCII can be used to "type" files available for download so they scroll across your screen. To enter the SYSOP mode press the ESC key locally or enter the special 'pass' and 'word' first and last name from a remote terminal. 18.1 SYSOP Commands Within RBBS-PC ---------------------------------- The following operations can then be performed by entering a number only at the command prompt: 1 - Type COMMENTS file. The contents of the COMMENTS file is displayed. This file can also be inspected using a TYPE command from DOS. It is a ASCII sequential text file. 2 - Type CALLERS file. A log is maintained of all persons who have called the system. This function will list the file showing the users name and the date and time signed on as well as the names of the files they upload/downloads along with any security violation or errors encountered. This is a random access file of 64-byte records. 3 - Resurrect a message. This function will return a message that has been killed to an active state. If message file has been "packed", the killed messages are no longer recoverable. The function will ask for the message number of the message to be recovered. 4 - Erase the COMMENTS file. This function will erase the comments file by killing the file. Since the file is opened "APPEND," a new comments file will be created the next time a user leaves a comment. 5 - USERS file maintenance. The users file contains entries for each user registered with the system. This function permits the SYSOP to A)dd -- add a user to the USERS file. L)st -- list the USERS file. P)rt -- print the USERS file on the printer. M)od -- modify a record in the USERS file. S)can - scan each record in the USERS file for a particular string. In <M>odify mode, limiting editing of the users record in the USERS file can be done. The following subfunctions are available: D - Delete a user in the USERS file. F - Find a user in the USERS file. M - Return to the option 5 function prompt. N - Give the user a new password. P - Toggle the printer flag to print entries on the printer. Q - Quit and return to the main message prompt. R - Reset the users graphic mode. S - Set the security level of the user. This can be used to lockout or grant special privileges to the user. # - locate any record number within the USERS file. Page 86 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 In <M>odify mode a record will be displayed followed by a subfunction prompt for action. To get to a specific record the record number can be entered at the prompt and if valid that record will be displayed. If the record number is invalid or an empty c/r is entered then the next record in the file will be displayed. 6 - Toggles the operator page bell on/off. This overrides the "office hours" specified in the RBBS-PC.DEF file. 7 - SYSOP drop to DOS as a remote user. If the SYSOP has logged on remotely and is running RBBS-PC under DOS 2.0 or greater, this function will dynamically setup a batch file to assign the SYSOPS terminal as the main console. It then returns to DOS and if a. CONFIG option 9 is equal to 1 with ringback equal to NO, and b. RBBS-PC was invoked via a batch file, and if c. that batch file checks for the batch file which RBBS-PC dynamically builds for option 7, and if d. the batch file that invokes RBBS-PC executes the batch file that RBBS-PC dynamically builds for option 7, and if The the SYSOP will then see the DOS prompt at the remote terminal and can execute whatever DOS commands or programs the CTTY command support. DOS will look for COMMAND.COM to be present on the disk drive you specified in option 85. Option 7, unlike "doors," loads in a copy of COMMAND.COM to run under the copy that was running RBBS-PC. Also be sure to read chapter 19 and make sure that you THOROUGHLY understands the limitations that DOS places on you when this option is invoked. Two areas of caution are advised when using option 7 under DOS 2.0 or above. First, each SYSOP should test what can be done remotely. Software that reads and writes directly to the video BIOS and does other things that bypass the standard input and output of DOS simply won't function correctly. Second, you should be aware that you are in DOS and can return to RBBS-PC only by issuing the EXIT command. This will return to the batch file that was built dynamically by RBBS-PC. This file will then continue executing and is designed to reassign the keyboard as the console and then re-invoke RBBS-PC. If you get disconnected while in DOS, your system will be locked up. The console will be assigned to your communication port and your Hayes modem will have dropped the line and will have been set not to auto-answer. The only way to re-boot the system is a manual power off/on sequence. 18.2 SYSOP's Use of Function Keys --------------------------------- The following function keys (ten keys on the left side of a standard IBM keyboard) are designed to give the SYSOP special local controls that can be actuated without entering the SYSOP mode (using the ESC entry key). The current status of the function keys F3, F4, F6 and F7 are displayed on line 25. F1 - Return to DOS. This will terminate a session if a caller is on-line. In a MultiLink environment when running RBBS-PC out of .BAT file that re- invokes itself it is difficult for a SYSOP to get out of RBBS-PC and exit to DOS locally using F1. To help, RBBS-PC now creates a special file on the same location as the CALLERS file called RBBSxF1.DEF (where "x" is the node ID -- RBBS6F1.DEF for node six). The .BAT file that would otherwise just re-invoke itself, can now check for the existence of this file and if Page 87 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 it finds it simply terminate itself. F2 - SHELL to DOS. RBBS-PC remains resident but suspended in memory, the user (if any) remains on-line and the local SYSOP is in DOS until the EXIT command is issued (returning to within RBBS-PC just prior to having pressed the F2 key). The users session is not terminated -- only suspended. F3 - Printer toggle on/off. This changes the printer on-line status. When on-line the printer will print each caller's name and the file names uploaded/downloaded. It will also print all error messages except the ERROR 68 used to check that a file exists. This function should match the condition of the printer. If the printer is going to be left off, the PRINTER toggle should be set to off. When the printer toggle is on, "LPT" will be displayed in positions 8-11 of line 25. F4 - Operator page toggle. This changes the status of "operator annoy" (i.e. allows the SYSOP to be pageable) and records the change in the "node" record associated with the copy of RBBS-PC associated with function key 4. This is set by the CONFIG program parameter # 7 which establishes the SYSOP's office hours. This can be used to override and extend the "office hours" set up by CONFIG.BAS. When the "operator annoy" toggle is on, "ANY" will be displayed in positions 5-7 of line 25. F5 - Forces RBBS-PC to tell the modem to answer the phone. F6 - SYSOP available. This changes the status of operator available and records the change in the "node" record associated with the copy of RBBS- PC associated with function key 6. This is useful if during your "office hours" you temporarily don't wish to be disturbed. When the SYSOP available toggle is on, "AVL" will be displayed in positions 1-3 of line 25. F7 - SYSOP gets control of the system after current user logs off. When the "SYSOP next" toggle is on, "SYS" will be displayed in positions 13-15 of line 25. F8 - Allows the SYSOP to grant an on-line user temporary SYSOP privileges. This is a toggle on/off switch. F9 - SNOOP toggle. This changes the SNOOP from the default value the first time it is pressed and toggles it on/off thereafter. "SNOOP off" clears the screen and turns the cursor off. It also keeps the download beeps from sounding. The SNOOP should be left off for normal use to keep the system startup screen from "burning into" the monitor. If the SNOOP is left on, the monitor should be physically turned off except when you are observing the RBBS in action. Leaving the monitor off will not affect performance of the RBBS. F10 - This is the forced chat switch. It announces your forced chat and who you are before turning the keyboard over to you and the caller. The ESC key is used to exit Forced chat mode or to answer an "O>perator page" request. The F10 key will not function until a user logging on has reached the Main Menu. END - Logs off and locks out the current user that is on and informs the user that their presence is unacceptable. PgUp - Displays all the information on a current user. This display is kept in the video page 1 (of the 0-7 pages). The user activity is always written to page 0 when SNOOP is active. The user sees no interruption when Page 88 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 this occurs as his activity continues unaffected. If you have a monochrome display there is no video pages 1 through 7 only page 0. This will display on the monochrome screen the user information. PgDn - Return to displaying video page 0 (i.e. the page that the users activity is written to when SNOOP is on). The SYSOP can also enter commands on the command prompt line while a caller is on-line. The command entered will cause the system to respond just as it would if the caller had entered the command. This should be used with caution because it could confuse a new system user -- users are often timid enough without knowing that big brother is actually watching them! Let callers page you and then tell them that you can assist with commands if the get into trouble. UP ARROW -- The keyboard "up arrow" key (i.e. one that generates the character with ASCII value 24 and which is the "8" key on the standard IBM keyboard's numeric pad that is at the left of the keyboard) allows the local SYSOP to increment an on-line users security level by one each time that it is pressed. DOWN ARROW -- The keyboard "down arrow" key (i.e. one that generates the character with ASCII value 25 and which is the "2" key on the standard IBM keyboard's numeric pad that is at the left of the keyboard) allows the local SYSOP to decrement an on-line users security level by one each time that it is pressed. 19.0 DOS LIMITATIONS ON RUNNING PROGRAMS REMOTELY ------------------------------------------------- 19.1 How to Get DOS to Monitor Carrier Detect --------------------------------------------- When accessing your PC via a communications port, the carrier detect signal tells the PC that you are on-line. DOS's major limitation is that there is no way to tell DOS to monitor carrier detect automatically when the standard input and output is transferred to a communication port (i.e. via the CTTY command). RBBS-PC makes sure that the carrier is not dropped when a user exits to DOS either via the "DOORS" option or using the remote SYSOP function 8. However, it is the SYSOP's responsibility to insure that whatever programs are invoked after leaving RBBS-PC perform all the necessary functions to maintain the communications session and, when exiting to return to RBBS-PC, that the carrier is "NOT" dropped. Most application programs (i.e. databases, etc.) are not designed to be controlled by users accessing them from a communications port. This problem is solved when a function is invoked that: 1. Checks to see if the standard input and output console have been assigned to an auxiliary console such as a communication port. 2. If condition 1 is true, checks to see if the carrier detect signal is lost by intercepting each interrupt from the communication port the auxiliary console has been assigned to. 3. If BOTH conditions 1 and 2 are true, this function would cause DOS to switch back to the standard screen and keyboard for its operations AND then continue processing whatever batch file that had been executing (if one was). Such a function (or device driver) would provide a "fail safe" feature that would allow users to exit RBBS-PC to use whatever other software the SYSOP chose to make available (i.e. relational databases for complex Page 89 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 inquiries -- bibliographic, sports, games, etc.). For those anticipating using RBBS-PC's "doors" or exiting to DOS when you are a remote SYSOP, you are strongly encouraged to consider using the "watchdog" utility program available on many bulletin board systems under such file names as WATCHDOG.COM, WATCHDOG.ASM, WATCHDOG.DOC, WATCHDOG.EXE that monitors the communication port for you and reboots your system if carrier drops. If you don't use a program like WATCHDOG and accidentally hang up while in a "door" or in DOS, you system will remain "hung" until you can manually reboot it. If you aren't technically inclined and want to use RBBS-PC "doors", I suggest you consider using MultiLink from The Software Link, Incorporated at (404) 998-0700. While MultiLink costs about $500 and neither RBBS-PC nor CPCUG have any connection with it, it does provide a mechanism for overcoming DOS's inability to have programs invoked from remote users (release 2.0.6 or higher of MultiLink is required). If RBBS detects that MultiLink is present when a user exits to DOS via "doors", RBBS-PC automatically passes control of the communications port that the user is on to MultiLink so that MultiLink can do the carrier monitoring on behalf of the application. 19.2 How to Redirect Graphic Displays to Remote Users ------------------------------------------------------ Programs that utilize the PC's built in video memory (such as the IBM BASIC interpreter or WordStar when it writes to the 25th line) need to have such I/O redirected in a special way to a remote users terminal. Additionally, if the I/O is redirected to the communications port, the terminal on the other end must have a "cursor" that can be sent the appropriate command sequence to move it around on the remote users terminal as necessary. Without this capability, programs made available through "doors" must be line-at-a-time programs. This of course excludes programs such as WordStar, Lotus/123 etc. If you aren't technically inclined and want to use RBBS-PC "doors" for applications that write directly to the PC's video hardware, I suggest you consider using MultiLink (see chapter 19). MultiLink provides a mechanism for overcoming DOS's inability to redirect graphics to remote users. If RBBS detects that MultiLink is present when a user exits to DOS via "doors", RBBS-PC automatically passes control of the communications port to MultiLink and notifies MultiLink of the kind of MultiLink-supported terminal to redirect the application's graphics to (presumably one with a controllable cursor). 20.0 CONFERENCING WITH RBBS-PC ------------------------------- RBBS-PC is intended to be an open system. The "conference" concept is one that allows either anyone who can leave messages (i.e. a "public" conference) or a pre-registered set of users (i.e. a "private" conference) to engage in a specialized dialogue. To make a "conference" successful several guidelines should be followed rather rigorously: 1. Establish a "conference chairman" (i.e. a SYSOP) to manage the conference. The SYSOP job is to add new users, delete old ones, make sure that the subject and/or the agenda of the conference is adhered to by killing messages that are inappropriate. 2. Establish an "agenda" or list of subject areas for the conference. One of these should be about new subject areas. These areas should be VERY narrow in scope. The essence of any good conference is keeping it focused. Everyone has been in at least one meeting/conference that was a waste of time because whoever was running the meeting/conference did not keep the Page 90 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 dialogue centered on the subject or agenda. The SYSOP sets up a conference using CONFIG.BAS to pre-format up to two files -- one for the messages to be associated with the conference and one for the users to be associated with a conference (if it is a "private" conference). The file name for a "conference" can be any seven characters that are valid for a file name. The eighth character must be a "M" (for the messages file associated the conference) or a "U" (for the users file associated with the conference). The SYSOP can then enter the conference member's names in the conference USERS file by using the SYSOP function 5. The SYSOP can "join" any conference and need not be in any particular conference's USERS file. To set up a conference chairman, the SYSOP need only 1. "Join" the conference, 2. Use SYSOP function 5 to enter the name of the user who is to be the conference chairperson into the conference's USERS file. 3. Set that users security level in the conference's USERS file to a security level that can issue the SYSOP function 5. This will allow the conference chairman to add users. Remember that users can join a "private" conference only if already registered in that conference's USERS file. Any registered user can join a "public" conference. When someone issues the J>oin command to join a conference, their standard security level is temporarily superseded by the security level associated with their user name within that conference's USERS file if it is a "private" conference. For example, a normal user might be given the security required to add users to the conference USERS file for a particular conference since they are the conference chairman. When a user joins the conference of which they are chairman, their normal security is bumped up so that they can add users to the USERS file of that particular "private" conference. When the same user exits that conference, their security level is returned to normal. If they should subsequently join another conference in which they are not chairman, they would be unable to add users to that conference's USERS file. Other than a conference chairman, none of the conference members should be given any higher security than they otherwise enjoy as a regular RBBS-PC users. There are no limits on the number of conferences within RBBS-PC. Here are some examples of some conference names: Conference Conference Message Conference Users Conference Welcome Name File Name File Name File Name FORSALE FORSALEM.DEF FORSALEU.DEF FORSALEW.DEF GAMES GAMESM.DEF GAMESU.DEF GAMESW.DEF FINANCE FINANCEM.DEF FINANCEU.DEF FINANCEW.DEF SYSOPS SYSOPSM.DEF SYSOPSU.DEF SYSOPSW.DEF CLONES CLONESM.DEF CLONESU.DEF CLONESW.DEF RELIGON RELIGONM.DEF RELIGONU.DEF RELIGONW.DEF PHILOSP PHILOSPM.DEF PHILOSPU.DEF PHILSPW.DEF BBS BBSM.DEF BBSU.DEF BBSW/DEF If a continuity of dialogue is to be achieved, it is advisable to keep the conference "focused" -- either by keeping the number of conference members limited to thirty persons or less or by keeping the subject matter very narrow (i.e. the IBM PC's 30MB disk size limitation). Another interesting thing about "private" conferences as implemented within RBBS-PC is that Page 91 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 they are not "public" and, therefore, are even more protected by the first, fourth, and fifth amendments. 21.0 RBBS-PC QUESTIONNAIRE FACILITIES ------------------------------------- RBBS-PC provides a highly sophisticated script-driven capability that allows a SYSOP to ask new users questions or questions of users when they say G>oodbye. To ask new users questions the file RBBS-REG.DEF must exist on the same disk as the WELCOME file. To ask questions of users when they say G>oodbye the file EPILOG.DEF must exist on the same disk as the the WELCOME file. The SYSOP can set up the script in such a way as to raise or lower a new users security level based on the answers. Contained within the script is the file to which the answers are to be written. RBBS-PC will only activate the corresponding script files if they exist, otherwise the functions are bypassed. The script files should be created with your favorite editor. During the testing phases both EDLIN and WordStar were used and both worked correctly. All "script" files are formatted the same and contain support for: o Branch to labels o Display lines o Display line and get response o Response validation (Multiple choice) o Numeric validation o Forward and backward branching o Raising and lowering user security level o Aborting the questionnaire The first line in every script file must contain the file name where the responses to the script will be appended as the first parameter and the maximum security level a users security level can be raised to as the second parameter.. This file can be any valid text type file. The rest of each script file must contain valid script commands. Script commands are 1 character in length and must be in column 1 of each script line. Following is a list and description of valid script commands: : A colon indicates a label command * An asterisk indicates a display data command ? A question mark indicates a display and wait for response command = An equal sign indicates a multiple choice branch command > A greater than symbol indicates a goto command + A plus sign indicates a raise security level command - A minus sign indicates a lower security level command @ An "at" sign means to abort questionnaire and do not write results : Colon (Label command) This command is used to provide labels that can be branched to from = and > commands. i.e. :QUESTION1 * Asterisk (Display data command) This command is used to send data to the user. i.e. *In order to better serve those who pass this way, I would ? Question mark (Display data and get response) This command is used to send data to the user and wait for a response. The user will be required to input a response. The ENTER key alone is Page 92 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 an invalid response. No other checks are made. i.e. ?DO YOU OWN YOUR OWN PC? (Y/N) = Equal sign (Response validation - Multiple choice) This command is used in conjunction with the ? command and must immediately follow the ? command for which it applies. This command allows for checking/editing of single character responses to the preceding ? command and allows branch logic to be exercised based on the response given. Multiple = commands must be coded on the same line. The format follows: =AXXXXXXXXX=BYYYYYYYYY= ZZZZZZZZZZ = Indicates that a single character comparison value follows A Is the comparison value X Is the label to branch to if the response is "A" = Indicates that a single character comparison value follows B Is the comparison value Y Is the label to branch to if the response is "B" = Indicates that a single character comparison value follows (SPACE) This is a special comparison value that is always used as the last comparison value and means "INVALID" response given Z Is the label to branch to if an invalid response is given Maximum line length is 255 characters and the last = on the line "MUST" have a comparison value of " " (SPACE). i.e. :QUESTION1 ?Do you run a BBS system. (Y/N) =YQUESTION2=NQUESTION2= QUESTION1E :QUESTION1E *Please respond Y or N >QUESTION1 :QUESTION2 There is an additional format for the = command, where the comparison value of # (Pound sign) is used. This is used as a numeric check and encompasses 0-9, (), - and space. This format requires two entries. The first is to test for numerics and the second is the invalid response branch label. i.e. =#QUESTION3= QUESTION2E > Greater than sign (Forward and backward branching) This command is used to branch to specific labels within the script file. i.e. >QUESTION4 + Plus sign (Raise user security level) This command will add the value in columns 2-6 to the default security level given new users or the current security level of old users. i.e. +5 - Minus sign (Lower user security level) This command will subtract the value in columns 2-6 to the default security given new users or the current security level of old users. i.e. -1 Page 93 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 @ At sign (Abort questionnaire) This command will terminate the questionnaire and NOT write the response to the output file. i.e. :QUESTION1 ?Have you answered the questionnaire before. (Y/N) =YQUESTION2=NQUESTION2= QUESTION1E :QUESTION1E *Please respond Y or N >QUESTION1 :QUESTION2 @ The following is a sample of an RBBS-PC "ASKUSER" script file: "RBBS-REG.DAT",6 *IN ORDER TO BETTER SERVE THOSE WHO PASS THIS WAY, I WOULD LIKE YOU TO *HELP ME BY ANSWERING A FEW QUESTIONS. * *THANK YOU, * *PLEASE ANSWER THE FOLLOWING QUESTIONS: :QUESTION1 ?DO YOU OWN YOUR OWN PC? (Y/N) =YQUESTION2=NQUESTION2= QUESTION1E :QUESTION1E *PLEASE RESPOND Y OR N >QUESTION1 :QUESTION2 *HOW OFTEN DO YOU CALL BBS SYSTEMS? *(A) = LESS THAN 1 TIME PER WEEK *(B) = 1-5 TIMES PER WEEK *(C) = 5-10 TIMES PER WEEK *(D) = MORE THAN 10 TIMES PER WEEK ?ENTER ONE OF THE ABOVE =AQUESTION3=BQUESTION3=CQUESTION3=DQUESTION3= QUESTION2E :QUESTION2E *PLEASE ENTER A,B,C OR D! >QUESTION2 :QUESTION3 ?ARE YOU A SYSOP OF A CURRENTLY OPERATING BBS SYSTEM? (Y/N) =YQUESTION4=NQUESTION6= QUESTION3E :QUESTION3E *PLEASE RESPOND Y OR N >QUESTION3 :QUESTION4 *WHICH BBS SYSTEM DO YOU RUN *(A) = RBBS-PC *(B) = HOSTCOM *(C) = BBS-PC *(D) = FIDO *(E) = PC-HOST *(F) = OTHER ?PLEASE ENTER ONE OF THE ABOVE =AQUESTION6=BQUESTION6=CQUESTION6=DQUESTION6=EQUESTION6=FQUESTION5= QUESTION4E :QUESTION4E *PLEASE ENTER A, B, C, D, E OR F >QUESTION4 :QUESTION5 ?ENTER THE NAME OF THE BBS SYSTEM THAT YOU RUN :QUESTION6 *THANK YOU FOR TAKING THE TIME TO ANSWER THESE FEW QUESTIONS. *I HOPE YOU ENJOY RBBS-PC. Page 94 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 22.0 RBBS-PC's EXTERNAL PROTOCOL DRIVERS ---------------------------------------- RBBS-PC attempts to nurture the maximum amount of diversity and innovation as possible. For this reason the source code has always been distributed. The free exchange of information, on of RBBS-PC's two primary objectives requires that communications occur. With PC's this communications is electronic and electronic communications fosters a multiplicity of "protocols" in which data can be exchanged. In order to provide advocates of specific protocols a means of adding their particular flavor of communications protocol to RBBS-PC a standard interface has been created. Before calling protocol drivers, RBBS-PC will perform the following: 1. verify that the file exists if the file is to be downloaded. 2. verify that the file name requested is valid if the file is to be uploaded. 3. pass the communications port to the vendor's protocol- handling routine with the file opened and carrier detect on. RBBS-PC will call the external protocol drivers either via the SHELL command in BASIC or via a .BAT file. 22.1 Parameters passed to a protocol driver. ---------------------------------------------- RBBS-PC sets up a command string for a protocol driver as follows: drive:path transfercommand nodeid The drive and path are where the protocol driver is to be found (i.e. C:\RBBS\KERMIT.EXE). The nodeid is the RBBS-PC node number (1 through 36). The transfer command has the following format: protocol [-x arg [-x arg]...[-yyy]..]] where protocol is the name of the .EXE or .COM file that is to be invoked as the protocol driver, x is an option that requires an argument and y is an option with no argument. The arguments passed are: 1.) Send or Receive indicator: -s filename send a file named "filename" or -r filename receive a file named "filename" 2.) Communications port indicator: -l comm port where "comm port" is COM1 or COM2 3.) Protocol indicator: protocol where protocol = A for ASCII X for XMODEM (checksum) C for XMODEM (crc) Y for YMODEM I for IMODEM G for YMODEM G W for XMODEM (windowed) N for KERMIT Page 95 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 4.) Communication speed indicator: -b baud where baud = 300 450 1200 2400 4800 9600 19200 5.) Maximum window size indicator: -m size where s is an integer between 1 and 31 (if not present the protocol driver uses its own default window size) 6.) Parity indicator: -p n where n indicates no parity 8 data bits 1 start bit or and one stop bit -n To send a file named "A:\UTIL\TEST.BAS" using the protocol driver named PCKERMIT.EXE for KERMIT located on drive C: in the DOS subdirectory named \RBBS at 9600 baud on COM2 with the window size set to 31 the command would be: C:PCKERMIT -s A:\UTIL\TEST.BAS -l COM2 -c -b 9600 -p n -m 31 To send the same file in the same way using the protocol driver for windowed XMODEM protocol driver named WXMODEM.EXE which can be found at the same place as the KERMIT protocol driver the command would be: C:WXMODEM -s A:\UTIL\TEST.BAS -l COM2 -c -b 9600 -p W -n 22.2 Parameters Returned by a Protocol Driver ---------------------------------------------- All protocol drivers are expected to return a file named XFER-xx where the value for xx is the node ID (1 to 36). This file may be either of two formats. It may consists of four records with each record having the parameters (i.e. parm1) surrounded by a double quote (i.e. ") and the record ending with a carriage return. An example of this type of format would be: "parm1" "parm2" "parm3" "parm4" The second format that this file may have is a single record with each parameter beginning and ending with a double quote (i.e. ") separated by commas and the record ending with a carriage return. An example of this type of format would be: "parm1","parm2","parm3","parm4" The only parameter of significance to RBBS-PC is the first letter of the fourth parameter. If it begins with an upper-case "S", RBBS-PC considers the file to have been successfully transferred. The other parameters may be anything the protocol driver might find useful (i.e. file name, size, date/time). Page 96 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 22.3 The Protocol Drivers Available for RBBS-PC ------------------------------------------------ RBBS-PC currently has the following protocol drivers available for RBBS-PC: 22.3.1 Columbia University's KERMIT Protocol -------------------------------------------- PCKERMIT.EXE is supplied by The Source as a public service and consists of sliding window KERMIT protocol. The development of "windowing" within the KERMIT architecture (i.e. Super KERMIT) was funded by The Source and implemented by Larry Jordan and Jan van der Eijk. The "windowing" is simply the number of blocks that can be sent before a positive acknowledgment is needed. In packet switching networks (such as Telenet and PC-Pursuit) where it takes a one-byte "ack" the same amount of time to travel back to the sender as a whole block, it is obvious that the efficiency is in reducing such handshaking between the sender and the receiver as much as possible. KERMIT has many similarities with RBBS-PC. It's source code is freely available to all, yet it is not in the "public domain." Columbia University holds the copyright and maintains the Kermit protocol. Like RBBS-PC, Columbia University allows KERMIT to be passed along to others and "ask only that profit not be your goal, credit be given where it is due, and that new material be sent back to us so that we can maintain a definitive and comprehensive set of KERMIT implementations". PCKERMIT.EXE is not a terminal program. It simply implements the Kermit protocol, including the sliding window extension. It will work with older "Kermit Classic" implementations as well, via automatic negotiation between the two Kermit programs. PCKERMIT.EXE runs as a "one-shot" execution then returns to RBBS-PC. PCKERMIT does not establish a carrier with a remote system. The connection is established by RBBS-PC, RBBS-PC then drops to DOS without disconnecting and invokes PCKERMIT.EXE. Since the documentation supplied by The Source with PCKERMIT.EXE explains the characters that are displayed and the keyboard control available to the local SYSOP during KERMIT file transfers, it is not replicated here. 22.3.2 YMODEM, YMODEMG, and IMODEM ---------------------------------- QMXFER.COM is supplied by The Forbin Project as a public service and supports five different protocols -- XMODEM (checksum), XMODEM (cylical redundancy check), YMODEM, YMODEMG, and IMODEM. QMXFER was implemented by John Friel III, author of QMODEM. YMODEM and YMODEMG are protocols designed by Chuck Frosberg. IMODEM is a protocol designed by John Friel. The later two are designed to work when the link between the two modems is "error free" (i.e. both modems have the MNP protocol built in)> QMXFER.COM runs as a "one-shot" execution then returns to RBBS-PC. QMXFER does not establish a carrier with a remote system. The connection is established by RBBS-PC, RBBS-PC then drops to DOS without disconnecting and invokes QMXFER.COM 22.3.3 Windowed XMODEM ---------------------- WXMODEM.COM is supplied by The Forbin Project as a public service and supports the window XMODEM protocol designed by Pete Boswell. Like all of RBBS-PC's protocol drivers, WXMODEM.COM runs as a "one-shot" execution then returns to RBBS-PC. WXMODEM does not establish a carrier with a remote system. The connection is established by RBBS- PC, RBBS-PC then drops to DOS without disconnecting and invokes WXMODEM.COM Page 97 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 23.0 UPLOADED FILE TIPS ----------------------- If someone uploads a BASIC file to you, and it will not list on your screen using the DOS TYPE command, you should go into BASIC, load the file, list it, then resave it using the same name. If when you try to load the file into the BASIC interpreter you get a `Direct Statement In File' error printed on the screen, the BASIC file has a line without a line number. This will not interfere with the resaving of the file unless the direct statement is at the beginning of the file; if the file lists properly, then the direct statement is at the end of the file. If the file does not list properly, then the direct statement is at the beginning of the file and has to be removed using a text editor (EDLIN) before the program can be loaded and run. Do not attempt to save a BASIC file after getting the `Direct Statement In File' error during loading without listing the program first; you will destroy the file otherwise. If you wish to load an uploaded file (a BASIC program or any other text file) into a text editor to change the content of the file, you will first have to first add line feeds to the end of each line (after each carriage return). Finally, every SYSOP should assume that any uploaded file him that can be executed (i.e. .BAS, .COM, .EXE) has the capability of destroying all the files available to the PC it is executed on. This may be because the documentation is in error, the program was executed incorrectly, or the program was designed to be malicious. It behooves every SYSOP to know what every uploaded file does in order to protect not only the RBBS-PC system, but its users. 24.0 DUE WARNING AND SYSOP'S LEGAL LIABILITY -------------------------------------------- While no definitive case-law or legislation exists defining the liabilities of System Operators, every SYSOP should assume that they are as responsible for their own actions when running an electronic bulletin board system as they would be for any other action as a citizen of the United States who chooses to exercise their right to freedom of speech. One of the unique features of RBBS-PC is that users have to OVERTLY register themselves -- even when the RBBS-PC is "open" to the general public. This gives each SYSOP the opportunity to give every user "due notice" and require each user to actively acknowledge such notice. For some SYSOP's it is simply the rules of their board. For me, the following is what I use as the text in my NEWUSER file: "Welcome to the world of RBBS-PC! Before continuing you should understand your responsibilities as a RBBS-PC user. Specifically they are: 1. Actively encourage and promote the free exchange and discussion of information, ideas and opinions, except when the content would compromise the national security of the United States; violate proprietary rights, personal privacy, or applicable state/federal/local laws and regulations affecting telecommunications; or constitute a crime or libel. 2. Use your real name and fully disclose any personal, financial, or commercial interest when evaluation any specific product or service. 3. Adhere to these rules and notify me immediately when you discover any violations of the rules. Page 98 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 FURTHER every user explicitly acknowledges that all information obtained from this RBBS-PC is provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to the implied warranties of merchantability and fitness for a particular purpose and that the entire risk of acting on information obtained from this RBBS-PC, including the entire costs of all necessary remedies, is with those who choose to act on such information and not the operator of this RBBS-PC. Register if you agree." This won't protect you from prosecution if you allow your RBBS-PC to be used for criminal activities. However, it does serve to cause each user to voluntarily and OVERTLY accept my "rules" and allows me to sleep better at night knowing that I have given "due notice." My own personal philosophy is to actively pursue and prosecute ANY user on my board who I find engaging in what appears to be a violation of the above notice. Essentially, if you are going to run an RBBS-PC open to the general public as I do, your board's reputation and standards must be able to withstand public scrutiny. If you don't feel you can maintain such standards, either don't run a RBBS-PC or run a very, very private one (and be sure to put all your assets in the wife's and kid's names). Since I'm not a lawyer, if you want a legal opinion on your liabilities as a SYSOP your only source of legal advice should be an attorney licensed to practice in your state. Just remember it may not be the best advice and that the legal liabilities regarding the operation of bulletin board systems is unclear. 25.0 COMPILING AND LINKING RBBS-PC ---------------------------------- RBBS-PC source code is distributed along with the executable program RBBS- PC.EXE. It is NOT necessary to recompile or re-link RBBS-PC in order to utilize RBBS-PC. However, some users may wish to modify the source and recompile it. This section is intended for those hardy few who choose to do so. Remember only what is distributed is supported -- anything else is strictly yours to debug! RBBS-PC's source code is compilable by the IBM BASIC Compiler Version 2.0 as released by IBM and with the IBM updates to it through 11/22/85. Subsequent patches released by IBM for the Version 2.0 compiler appear to disable the compiler to the point where it can not compile RBBS-PC. RBBS- PC's source code is compilable by Microsoft's QuickBASIC Compiler -- both version 1.0 and version 1.02. However Microsoft's QuickBASIC Compiler version 1.01 appears to be unable to compile RBBS-PC. Microsoft's QuickBASIC Compiler version 2.0 generates faster code than the earlier versions but has some bugs of its own that cause strange results if you have ANSI.SYS option activated (from RBBS-PC's CONFIG) or if you use the PgUp or PgDn keys as described. QuickBASIC Compiler Version 2.01 seems to have corrected the problems encountered with 2.0. 25.1 Compiling CONFIG and RBBS-PC --------------------------------- Version CPC15-1B of RBBS-PC's .EXE file is distributed after having been compiled with QuickBASIC Version 2.01 compiler that had the DTR patch described in Appendix R applied to it. CONFIG.EXE is generated from compiling with multiple BASIC source files -- CNFG-VAR.BAS, CONFIG.BAS, CNFG-SUB.BAS. The output of the multiple compiles (CONFIG.OBJ and CNFG-SUB.OBJ) generate multiple .OBJ input files to the LINK step that create CONFIG.EXE. Page 99 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 The BASIC compiler command to compile for all but the QuickBASIC version 2.0 compiler should be: BASCOM CONFIG.BAS,, /E/O/C:2048; BASCOM CNFG-SUB.BAS,, /E/O; The command for QuickBASIC version 2.0 is slightly different and should be: QB CONFIG.BAS /E /O /C:2048; QB CNFG-SUB.BAS /E /O; Compiling CONFIG requires that CNFG-VAR.BAS be in the sub-directory from which they are being compiled. RBBS-PC.EXE is generated from compiling with multiple BASIC source files -- RBBS-VAR.BAS, RBBS-PC.BAS, RBBSSUB1.BAS, RBBSSUB2.BAS. The output of the multiple compiles (RBBS-PC.OBJ, RBBSSUB1.OBJ, and RBBSSUB2.OBJ) generate multiple .OBJ input files to the LINK step that, along with some other .OBJ files, create RBBS-PC.EXE. The BASIC compiler command for all but the QuickBASIC version 2.0 compiler should be: BASCOM RBBS-PC.BAS,, /E/C:4096/O; BASCOM SB1151A.BAS,, /X/C:4096/O; BASCOM SB2151A.BAS,, /O; The command for QuickBASIC version 2.0 is slightly different and should be: QB RBBS-PC.BAS /E /C:4096 /O; QB RBBSSUB1.BAS /X /C:4096 /O; QB RBBSSUB2S.BAS /O; If you are utilizing the IBM BASIC compiler Version 2.0, you will need to also use the /N parameter when compiling. Compiling RBBS-PC requires that RBBS-VAR.BAS be in the sub-directory from which they are being compiled. The BASIC compiler library routines have a NASTY bug in them for those who would like to allow KERMIT protocol to be used, exit to DOS as a remote SYSOP, or exit to a "door." If you re-compile RBBS-PC and desire to utilize any of these three RBBS-PC functions, YOU MUST patch your compiler's libraries as described in Appendix R.! 25.2 LINKing CONFIG ------------------- CONFIG.OBJ can be LINKed to produce CONFIG.EXE with the command LINK CONFIG+CNFG-SUB+RBBSUTIL+xxxCOM,CONFIG.EXE,,C:/E; assuming that all the required files are on the C drive. NOTE: xxxCOM must be replaced with GWCOM if using the QuickBASIC compiler and IBMCOM if using the IBM Version 2.0 compiler. Also, if using the QuickBASIC compiler you may also want to link with the .OBJ file that accompanies the compiler called PREFIX. Page 100 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 25.3 LINKing RBBS-PC -------------------- RBBS-PC.OBJ can be LINKed to produce RBBS-PC.EXE with the LINKer command (all on one line): LINK RBBS-PC+RBBSSUB1+RBBSSUB2+xxxCOM+QBARCV2+ANSI+XMODEM+RBBSML+BDRIVEC2+ PC-NET+10NET+RBBSUTIL+RBBSDV+PREFIX,,,/MAP/LINE; NOTE: xxxCOM must be replaced with GWCOM if using the QuickBASIC compiler and IBMCOM if using the IBM Version 2.0 compiler. PREFIX is only required if linking with Microsoft's QuickBASIC compiler output. XMODEM.OBJ and RBBSUTIL.OBJ are different .OBJ from earlier versions OF RBBS-PC. MAKE SURE YOU HAVE THE CORRECT ONE! The above LINK command assumes that all the necessary .OBJ files are on the default drive and the necessary .LIB files are on the "C" drive. 26.0 LIMITED LICENSE -------------------- The RBBS-PC software is copyrighted but A LIMITED LICENSE IS GRANTED and each user is free to use and share it under the following conditions: 1. You may NOT distribute RBBS-PC in modified form. 2. You may NOT charge a fee for RBBS-PC itself, and 3. You MUST retain all references to the copyright and authors. Please distribute the original version (or update thereof) of the program. If you have changes please distribute them using the conventions described in section 1.4. This is necessary so that future revisions can be easily added to the system without requiring the entire program. Please do NOT resequence the program. All revisions will be as files that replace the base program or update thereof and the existing line numbers will be referenced when describing new fixes and enhancements. 27.0 LIMITED WARRANTY --------------------- The RBBS-PC program is provided "as is" without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the the quality and performance of the program is with the user, and should the program prove defective, the user and not the authors will assume the entire cost of all necessary remedies. None of the authors warrant that the functions contained in the program will meet any users' requirements or that the operation of the program will be uninterrupted or error-free. In any case, each author's entire liability will be limited to the total amount of money the individual user paid directly and explicitly to each author for the use of RBBS-PC. 28.0 UPGRADING FROM CPC14-1D TO CPC15-1B ---------------------------------------- Before upgrading from CPC14-1D to CPC15-1B, you should follow these five steps: 1. Create backup files of all your current USERS, MESSAGES, and RBBSxPC.DEF files. 2. Print out all the options you selected on your current RBBSxPC.DEF file. Page 101 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 3. Delete your current RBBSxPC.DEF file. 4. Run CONFIG, version 3.02 and re-enter the options you had selected. 5. If you have a Hayes 2400 modem make sure that you use CONFIG to initialize the Hayes 2400 default settings. PLEASE NOTE!!!!! ---- CPC15-1B has a new CONFIG.BAS (version 3.02) that replaces the older versions of CONFIG.BAS and the .DEF files that they created! While CPC14-1D's .DEF file (from CONFIG.BAS version 2.20) may appear to work, you will get unusual results. CPC15-1A's .DEF file (from CONFIG.BAS version 3.01) is compatible with 15-1B. Some of the new options in 15-1B are not available in version 3.01 of CONFIG -- only in version 3.02! If you wish to convert to the new File Management System (FMS), follow the documentation included with the utilities in CNVDIR.ARC. If you haven't run RBBS-PC, prior to receiving 15-1B, there is no need to use the files contained in CNVDIR.ARC. 29.0 PROPOSED AGENDA FOR A NATIONAL SYSOP CONFERENCE ---------------------------------------------------- As PC's (IBM's and others) become more common in homes and offices, their use as vehicles for information exchange continues to grow -- as so eminently attested by the astounding growth of RBBS-PC itself! A national meeting of SYSOP's could foster this growth in information exchange; assist in focusing on the issues (regulatory and otherwise) that foster/inhibit this growth; and act as a forum for new ideas. A national meeting, perhaps sponsored by the Capital PC User Group or even a consortium of other not-for-profit PC user groups could be held . SYSOP's are not only in the big corporations but also in the millions of small businesses, non-profit associations, educational institutions in which the RBBS-PC concept has found a home. They are often the decision influencers in their organizations or area -- as U.S. Robotics discovered when they introduced their Courier 2400 baud modem so successfully. As I expect most who would attend would be paying their own way, the first conference would probably consist of that small "band of brothers" who have set up boards out of the intensity of their own commitment. My own vision of such a conference is sort of a 1980's electronic "Woodstock" -- if for no other reason because of the very "volks" nature of SYSOPS. It has been a long time since there has been a conference "of the people, by the people, and for the people." What follows is a hypothetical agenda of what might be of interest at such a conference. The agenda consists of a "technical" and a "non-technical" (management?) set of sessions as follows: "technical sessions" "non-technical sessions" 8:30 - 10:00 RBBS-PC Record Layouts How to Copyright Software -- (CALLERS, USERS, and its protection and penalties MESSAGES files) for violation of copyrights. 10:30 - 12:00 Multi-Port RBBS-PC 1986 Computer Privacy Act and Systems -- actual "computer trespass" laws at experiences. the State level. Page 102 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 12:00 - 1:30 Luncheon with a nationally known guest speaker (any suggestions?) 1:30 - 3:00 RBBS-PC "doors" and Business Applications of "doorware" explained. Bulletin Board Systems 3:30 - 5:00 Modems -- beyond 2400 The use of RBBS-PC in local, baud. State, and Federal agencies. 5:00 - 6:30 CONNECT TIME! -- Vendor Presentations and Receptions If you are with a manufacturer or organization that might be interested in sponsoring such a meeting, work with your organization to make it happen! If in the normal course of your business contacts you see a potential sponsor of such a conference, persuade them to look into being a sponsor. I would be glad to talk with anyone about going forward with this project. If you are interested in participating, write me at the following address: Tom Mack National SYSOP Conference 10210 Oxfordshire Road Great Falls, Virginia 22066 Please indicate 1. Which four sessions you would attend (in order of preference). 2. Any additional sessions you would be interested in. 3. Who would you want as a guest speaker at the luncheon. 4. Where you would like such a conference held from among the following five locations: a.) Boston, Mass. b.) Chicago, Ill. c.) Houston, Texas d.) San Francisco, Calif. e.) Washington, D.C. 5. Your mailing address. 6. Telephone numbers you can be reached at (both voice and data). 7. And if you would be willing to be a "worker" as well as an attendee -- i.e. stuff envelopes, keep the mailing list, make hotel arrangements, etc. My greatest fear is not that there will be fifty of us -- but that there will be 2,000 of us! Whatever happens, it should be fun. 30.0 RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD --------------------------------------------------------- RBBS-PC'S "Userware" concept is founded on the principle stated in section 1.0 -- "software which is shared becomes better than it was." Relying on Page 103 of 149 RBBS-PC CPC15-1B, Copyright 1987 by D. Thomas Mack June 7, 1987 Federal copyright protection, it is my firm belief that RBBS-PC's source code can be distributed without the risk of "loss of ownership" (i.e. it becoming "public domain"). In fact I think that all software (commercial and non-commercial) should be distributed as both compiled/executable files and with their source code. With one exception, RBBS-PC's copyrights have never been violated -- this is due more to the fact that RBBS-PC enthusiasts are ever-vigilant of RBBS-PC's copyrights rather than due to any lack of attempts to "sell" RBBS-PC or RBBS-PC look-alikes to the unsuspecting public. Incorporating these new features and ideas into each new release of RBBS- PC, making sure that upward compatibility with earlier version of RBBS-PC exists, as well as maintaining RBBS-PC's copyright, are all things that I accept the responsibility for. However, it is RBBS-PC's "support staff" (i.e. all those who enhance RBBS-PC and share such enhancements) that continues to make RBBS-PC a unique experiment in PC software. No one should feel that the possibilities for RBBS-PC have even begun to be exhausted. In fact, I am absolutely certain that even as this is written innovative enhancements are being created for RBBS-PC that I haven't even mentioned. It is my sincerest hope that if RBBS-PC continues to succeed within the IBM PC industry in becoming the "bulletin-board standard," software vendors will begin examining the reasons for RBBS-PC's success and come to understand that 1. The best form of software support is user support; 2. The best source for software enhancements are from it's users; 3. The best software continually adopts itself to users needs; and 4. The best way to minimize software development is to distribute source code; Each RBBS-PC system operator has the opportunity to affect what RBBS-PC becomes in the future. Many already have. RBBS-PC continues to grow and expand because hundreds (and quite possibly thousands) of SYSOP's spend the time and trouble not only to modify RBBS-PC to meet their needs, but also to share these modifications with others. I do not know of any other software for the IBM PC that has such a vast number of programmers supporting it. In section 1.3, I name more than 70 such individuals and acknowledge that there are a lot more! With the structured design RBBS- PC's source code that the new BASIC compilers allowed, even more RBBS-PC system operators are invited to contribute. Take the time! Make the difference! Page 104 of 149